From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: [PATCH] add sysfs mem device support [2/4]
Date: Tue, 23 Dec 2003 18:01:27 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-107220277102777@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-107213954018345@msgid-missing>
On Tue, Dec 23, 2003 at 01:15:23PM +0000, Christoph Hellwig wrote:
> On Mon, Dec 22, 2003 at 04:26:09PM -0800, Greg KH wrote:
> > This adds /sys/class/mem which enables all mem char devices to show up
> > properly in udev.
> >
> > Has been posted to linux-kernel every so often since last July, and
> > acked by a number of other kernel developers.
>
> This is pointless. The original point of sysfs and co was to present the
> physical device tree, where these devices absolutely fit into.
No. The point of sysfs and co was to present the physical _and_ logical
device tree. Mem devices are devices. This patch also provides a place
to move the /proc/sys/kernel/random files out of proc and into sysfs.
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.
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.)
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.)
I do agree that the duplication of the code should be fixed, and I'll go
do that right now (I should have realized that after cut-and-pasting
that logic the third time, sorry about that.) If that is done, the
overhead to support mem devices will drop to a very tiny ammount.
thanks,
greg k-h
-------------------------------------------------------
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 18:01 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 [this message]
2003-12-23 19:16 ` Christoph Hellwig
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-107220277102777@msgid-missing \
--to=greg@kroah.com \
--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).