From: Christoph Hellwig <hch@infradead.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: [PATCH] add sysfs mem device support [2/4]
Date: Tue, 23 Dec 2003 19:16:34 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-107220712507104@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-107213954018345@msgid-missing>
On Tue, Dec 23, 2003 at 10:01:27AM -0800, Greg KH wrote:
> In order for tools like udev to work, we must export all char devices
> that are registered with the kernel. We can't do this at
> register_chrdev() time, as that only allocates a whole major. And
> people haven't converted over to using register_chrdev_region only when
> they really have a device present yet.
Then add a random-junk-not-converted-yet devclass instead of duplicting
the adhoc code everywhere. Still I'd vote for going to the proper interface
directly instead of adding bad hacks all over the places. If that means
waiting for 2.7 to open, so what?
> With devices such as the misc devices, we only care about the devices we
> really have in the system at that time. It also gives us the ability to
> show the linkage between the logical device, and the physical one (for
> misc devices.)
But why is it tied to the obsoltet misc mechanism (or the obsolete usb major
thing, etc..)
> Now yeah, I can see that some people might think it's a bit overkill to
> move the mem devices here, but why not? They are logical devices in the
> system, and as stated above, it provides a place within sysfs to move
> user modifiable attributes of these devices out of /proc (as they do not
> pertain to anything related to processes.)
What user-modifiable attributes?
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2003-12-23 19:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-23 0:26 [PATCH] add sysfs mem device support [2/4] Greg KH
2003-12-23 13:15 ` Christoph Hellwig
2003-12-23 15:31 ` Rob Love
2003-12-23 16:07 ` Rob Love
2003-12-23 16:39 ` Christoph Hellwig
2003-12-23 17:56 ` Rob Love
2003-12-23 18:01 ` Greg KH
2003-12-23 19:16 ` Christoph Hellwig [this message]
2003-12-23 19:19 ` Rob Love
2003-12-23 19:22 ` Christoph Hellwig
2003-12-23 19:24 ` viro
2003-12-23 19:25 ` Rob Love
2003-12-23 19:28 ` Rob Love
2003-12-23 19:42 ` Jeff Garzik
2003-12-23 19:45 ` Rob Love
2003-12-23 20:00 ` Stephan Maciej
2003-12-23 20:33 ` viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-hotplug-107220712507104@msgid-missing \
--to=hch@infradead.org \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).