* State of devfs in 2.6? @ 2003-12-08 15:36 Andrew Walrond 2003-12-08 15:42 ` William Lee Irwin III 2003-12-08 23:35 ` Greg KH 0 siblings, 2 replies; 103+ messages in thread From: Andrew Walrond @ 2003-12-08 15:36 UTC (permalink / raw) To: linux-kernel Whats the general feeling about devfs now? I remember Christoph and others making some nasty remarks about it 6months ago or so, but later noted christoph doing some slashing and burning thereof. Is it 'nice' yet? Andrew Walrond ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 15:36 State of devfs in 2.6? Andrew Walrond @ 2003-12-08 15:42 ` William Lee Irwin III 2003-12-08 15:59 ` Andrew Walrond ` (2 more replies) 2003-12-08 23:35 ` Greg KH 1 sibling, 3 replies; 103+ messages in thread From: William Lee Irwin III @ 2003-12-08 15:42 UTC (permalink / raw) To: Andrew Walrond; +Cc: linux-kernel On Mon, Dec 08, 2003 at 03:36:26PM +0000, Andrew Walrond wrote: > Whats the general feeling about devfs now? I remember Christoph and others > making some nasty remarks about it 6months ago or so, but later noted > christoph doing some slashing and burning thereof. > Is it 'nice' yet? > Andrew Walrond I would say it's deprecated at the very least. sysfs and udev are supposed to provide equivalent functionality, albeit by a somewhat different mechanism. -- wli ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 15:42 ` William Lee Irwin III @ 2003-12-08 15:59 ` Andrew Walrond 2003-12-08 23:38 ` Greg KH 2003-12-09 5:04 ` Rob Landley 2003-12-08 19:09 ` udev sysfs docs " Bob 2003-12-08 23:04 ` Andreas Jellinghaus 2 siblings, 2 replies; 103+ messages in thread From: Andrew Walrond @ 2003-12-08 15:59 UTC (permalink / raw) To: linux-kernel On Monday 08 Dec 2003 3:42 pm, William Lee Irwin III wrote: > > I would say it's deprecated at the very least. sysfs and udev are > supposed to provide equivalent functionality, albeit by a somewhat > different mechanism. > Thanks for the pointer. So how good is the device coverage offered by sysfs/udev ? Do they provide a viable/complete MAKEDEV replacement yet? ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 15:59 ` Andrew Walrond @ 2003-12-08 23:38 ` Greg KH 2003-12-09 10:37 ` Andrew Walrond 2003-12-09 5:04 ` Rob Landley 1 sibling, 1 reply; 103+ messages in thread From: Greg KH @ 2003-12-08 23:38 UTC (permalink / raw) To: Andrew Walrond; +Cc: linux-kernel On Mon, Dec 08, 2003 at 03:59:04PM +0000, Andrew Walrond wrote: > > So how good is the device coverage offered by sysfs/udev ? Do they provide a > viable/complete MAKEDEV replacement yet? It works for me on my laptop :) You might have different devices and need other things. If so, please let me know after trying it out. greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 23:38 ` Greg KH @ 2003-12-09 10:37 ` Andrew Walrond 2003-12-09 10:57 ` Måns Rullgård 2003-12-09 12:54 ` Paul P Komkoff Jr 0 siblings, 2 replies; 103+ messages in thread From: Andrew Walrond @ 2003-12-09 10:37 UTC (permalink / raw) To: linux-kernel My initial query has thrown up lots of interesting debate :) I, like most people I suspect, love the concept of a complete auto-populated dev directory, and not having to MAKEDEV. devfs provided this, but like most people who read LKML, I stopped using it when it's problems were discussed. I really hope udev lives up to its promise, unlike devfs. Manually creating / dev just annoys me for no apparent reason other than it's plain inelegance I suppose. Andrew Walrond ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 10:37 ` Andrew Walrond @ 2003-12-09 10:57 ` Måns Rullgård 2003-12-09 12:54 ` Paul P Komkoff Jr 1 sibling, 0 replies; 103+ messages in thread From: Måns Rullgård @ 2003-12-09 10:57 UTC (permalink / raw) To: linux-kernel Andrew Walrond <andrew@walrond.org> writes: > My initial query has thrown up lots of interesting debate :) > > I, like most people I suspect, love the concept of a complete auto-populated > dev directory, and not having to MAKEDEV. So do I. > devfs provided this, but like most people who read LKML, I stopped using it > when it's problems were discussed. > > I really hope udev lives up to its promise, unlike devfs. Manually creating / > dev just annoys me for no apparent reason other than it's plain inelegance I > suppose. Does anyone else remember all the talk about the supreme elegance of devfs back when it was new? -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 10:37 ` Andrew Walrond 2003-12-09 10:57 ` Måns Rullgård @ 2003-12-09 12:54 ` Paul P Komkoff Jr 1 sibling, 0 replies; 103+ messages in thread From: Paul P Komkoff Jr @ 2003-12-09 12:54 UTC (permalink / raw) To: linux-kernel Replying to Andrew Walrond: > My initial query has thrown up lots of interesting debate :) > > I, like most people I suspect, love the concept of a complete auto-populated > dev directory, and not having to MAKEDEV. > > devfs provided this, but like most people who read LKML, I stopped using it > when it's problems were discussed. > > I really hope udev lives up to its promise, unlike devfs. Manually creating / > dev just annoys me for no apparent reason other than it's plain inelegance I > suppose. The one of main benefits I considered when focusing my attention on devfs-like approach is space consumption. Somewhat-populated dev subdirectory (looking at fedora 1) have about 7k items inside, each of them eating its inode and (depends on underlying fs) a block. I agree that previous implementation may be racy, domb, gooched, whatever. but is it sane that for system to function correcly I should carry over a whole bunch of directory entries, when I actually have all information about it in kernel, somewhere buried under major-minor declarations. That is, udev backed on tmpfs approach are almost solving our problem. But not completely. Module autoloading is useful, actually, was useful in conjunction with module unloading - if unloading support is poor autoloading is almost useless ... -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 15:59 ` Andrew Walrond 2003-12-08 23:38 ` Greg KH @ 2003-12-09 5:04 ` Rob Landley 1 sibling, 0 replies; 103+ messages in thread From: Rob Landley @ 2003-12-09 5:04 UTC (permalink / raw) To: Andrew Walrond, linux-kernel On Monday 08 December 2003 09:59, Andrew Walrond wrote: > On Monday 08 Dec 2003 3:42 pm, William Lee Irwin III wrote: > > I would say it's deprecated at the very least. sysfs and udev are > > supposed to provide equivalent functionality, albeit by a somewhat > > different mechanism. > > Thanks for the pointer. > > So how good is the device coverage offered by sysfs/udev ? Do they provide > a viable/complete MAKEDEV replacement yet? My understanding is that udev takes the information exported by sysfs about what devices exist in the system, and creates device nodes in /dev (which can be a ramfs mount or part of a persistent filesystem, udev itself doesn't care). I'm guessing it traverses sysfs to see what the system's got on startup (some variant of "find /sys -name device", perhaps) and then receives hotplug events when new devices are added later. On the whole, this is generally cool, hotplug friendly, and small and simple. _and_ the result looks like a recognizable /dev directory, so end-user applications don't have to be "devfs aware" (which was a bad sign from day 1 if you ask me). Unfortunately, sysfs doesn't yet export device node information for everything in the system yet. (There aren't any under /sys/cdev, /sys/devices/legacy, or /sys/devices/system, for example). There are pending patches to add more, but they're not considered bug fixes, so Linus won't take them before 2.6.0 and we'll have to wait until after 2.6.0 for development on this subsystem to finish. Probably somewhere in the 2.6.4 to 2.6.6 timeframe, sysfs will have all the device exports udev needs. (Or at least all the ones anybody's complained about yet.) Until then... dunno. Maybe you can use a /dev directory on a persistent filesystem that you mknod any extra devices you need into yourself?) Rob ^ permalink raw reply [flat|nested] 103+ messages in thread
* udev sysfs docs Re: State of devfs in 2.6? 2003-12-08 15:42 ` William Lee Irwin III 2003-12-08 15:59 ` Andrew Walrond @ 2003-12-08 19:09 ` Bob 2003-12-08 23:37 ` Greg KH 2003-12-08 23:04 ` Andreas Jellinghaus 2 siblings, 1 reply; 103+ messages in thread From: Bob @ 2003-12-08 19:09 UTC (permalink / raw) To: linux-kernel William Lee Irwin III wrote: >On Mon, Dec 08, 2003 at 03:36:26PM +0000, Andrew Walrond wrote: > > >>Whats the general feeling about devfs now? I remember Christoph and others >>making some nasty remarks about it 6months ago or so, but later noted >>christoph doing some slashing and burning thereof. >>Is it 'nice' yet? >>Andrew Walrond >> >> > >I would say it's deprecated at the very least. sysfs and udev are >supposed to provide equivalent functionality, albeit by a somewhat >different mechanism. > > >-- wli > Where can we find documentation on sysfs and udev, and on transition issues? I know devfs hasn't been maintained for a long time but the documentation for it comes with kernel source and there it is in menuconfig. Every time I hear that udev and sysfs replace devfs I wonder where to pick up the thread, where is that doc, where is the menuconfig option ;-) I guess there is a website but to bring people out of devfs with their /etc/devfs/compat_symlinks necessary to boot so they will have to manually make edits, it would be necessary to research the manual edits it takes to boot (md0 vs. md/0, tty vs. vc, etc., /etc/inittab, maybe etc pam or security ). If transitioning from devfs to udev sysfs comes down to one mistake so I can't boot and have to lilo append="rw init=/bin/bash" and edit /etc/innitab then I need the doc on boot partition to make the last edits to transition completely and save myself (not docs on a website). Shouldn't udev sysfs doc come with kernel source(maybe it does!?)? -Bob ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-08 19:09 ` udev sysfs docs " Bob @ 2003-12-08 23:37 ` Greg KH 2003-12-09 5:17 ` Witukind 0 siblings, 1 reply; 103+ messages in thread From: Greg KH @ 2003-12-08 23:37 UTC (permalink / raw) To: Bob; +Cc: linux-kernel On Mon, Dec 08, 2003 at 02:09:47PM -0500, Bob wrote: > William Lee Irwin III wrote: > > >On Mon, Dec 08, 2003 at 03:36:26PM +0000, Andrew Walrond wrote: > > > > > >>Whats the general feeling about devfs now? I remember Christoph and > >>others making some nasty remarks about it 6months ago or so, but later > >>noted christoph doing some slashing and burning thereof. > >>Is it 'nice' yet? > >>Andrew Walrond > >> > >> > > > >I would say it's deprecated at the very least. sysfs and udev are > >supposed to provide equivalent functionality, albeit by a somewhat > >different mechanism. > > > > > >-- wli > > > Where can we find documentation on sysfs and udev, > and on transition issues? Oh come on, google for "udev FAQ". It's been posted here a number of times... > I know devfs hasn't been maintained for a long time but the > documentation for it comes with kernel source and there it is in > menuconfig. udev is a user program, and it's documentation is not in the kernel tree. It's within the source of udev, and is quite extensive. > Every time I hear that udev and sysfs replace devfs I > wonder where to pick up the thread, where is that doc, > where is the menuconfig option ;-) There is neither. You always get sysfs in 2.6, and udev is a user program. No kernel options to enable (well, you do need CONFIG_HOTPLUG enabled I guess...) Please read the udev docs and FAQ, it is there for a reason. greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-08 23:37 ` Greg KH @ 2003-12-09 5:17 ` Witukind 2003-12-09 7:21 ` Bob 2003-12-09 7:56 ` Greg KH 0 siblings, 2 replies; 103+ messages in thread From: Witukind @ 2003-12-09 5:17 UTC (permalink / raw) To: Greg KH; +Cc: recbo, linux-kernel On Mon, 8 Dec 2003 15:37:55 -0800 Greg KH <greg@kroah.com> wrote: > On Mon, Dec 08, 2003 at 02:09:47PM -0500, Bob wrote: > > William Lee Irwin III wrote: > > > > >On Mon, Dec 08, 2003 at 03:36:26PM +0000, Andrew Walrond wrote: > > > > > > > > >>Whats the general feeling about devfs now? I remember Christoph > > >and >others making some nasty remarks about it 6months ago or so, > > >but later >noted christoph doing some slashing and burning thereof. > > >>Is it 'nice' yet? > > >>Andrew Walrond > > >> > > >> > > > > > >I would say it's deprecated at the very least. sysfs and udev are > > >supposed to provide equivalent functionality, albeit by a somewhat > > >different mechanism. >From the udev FAQ: Q: But udev will not automatically load a driver if a /dev node is opened when it is not present like devfs will do. A: If you really require this functionality, then use devfs. It is still present in the kernel. Will it have this 'equivalent functionality' some day? -- Jabber: heimdal@jabber.org ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 5:17 ` Witukind @ 2003-12-09 7:21 ` Bob 2003-12-09 7:39 ` Matthew Reppert ` (2 more replies) 2003-12-09 7:56 ` Greg KH 1 sibling, 3 replies; 103+ messages in thread From: Bob @ 2003-12-09 7:21 UTC (permalink / raw) To: linux-kernel Witukind wrote: >On Mon, 8 Dec 2003 15:37:55 -0800 >Greg KH <greg@kroah.com> wrote: > > > >>On Mon, Dec 08, 2003 at 02:09:47PM -0500, Bob wrote: >> >> >>>William Lee Irwin III wrote: >>> >>> >>> >>>>On Mon, Dec 08, 2003 at 03:36:26PM +0000, Andrew Walrond wrote: >>>> >>>> >>>> >>>> >>>>>Whats the general feeling about devfs now? I remember Christoph >>>>> >>>>> >>>>and >others making some nasty remarks about it 6months ago or so, >>>>but later >noted christoph doing some slashing and burning thereof. >>>> >>>> >>>>>Is it 'nice' yet? >>>>>Andrew Walrond >>>>> >>>>> >>>>> >>>>> >>>>I would say it's deprecated at the very least. sysfs and udev are >>>>supposed to provide equivalent functionality, albeit by a somewhat >>>>different mechanism. >>>> >>>> > >>From the udev FAQ: > >Q: But udev will not automatically load a driver if a /dev node is opened > when it is not present like devfs will do. >A: If you really require this functionality, then use devfs. It is still > present in the kernel. > >Will it have this 'equivalent functionality' some day? > > > > Shouldn't hotplug handle it? hotplug and udev and sysfsutils are together at http://www.kernel.org/pub/linux/utils/kernel/hotplug so hotplug is part of the sysfs and udev program. -Bob D ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 7:21 ` Bob @ 2003-12-09 7:39 ` Matthew Reppert 2003-12-09 8:52 ` Måns Rullgård 2003-12-09 9:16 ` Greg KH 2003-12-09 9:18 ` Greg KH 2003-12-09 9:46 ` Andreas Jellinghaus 2 siblings, 2 replies; 103+ messages in thread From: Matthew Reppert @ 2003-12-09 7:39 UTC (permalink / raw) To: Bob; +Cc: linux-kernel, witukind On Tue, 2003-12-09 at 01:21, Bob wrote: > Witukind wrote: > > >From the udev FAQ: > > > >Q: But udev will not automatically load a driver if a /dev node is opened > > when it is not present like devfs will do. > >A: If you really require this functionality, then use devfs. It is still > > present in the kernel. > > > >Will it have this 'equivalent functionality' some day? > > > > > > > > > Shouldn't hotplug handle it? How would hotplug handle it? Or, more directly ... on my system, /dev is just a normal directory on an ext2 filesystem. If something tries to open a file on it that doesn't exist, open will just return ENOENT. How is open supposed to know that someone is trying to open a device node? The naive solution is to conditionally check for the presence of "/dev" at the beginning of all requested filenames that don't exist, which strikes me as ... well, not necessarily a good idea. (I can't really say why beyond gut feeling.) My guess is, unfortunately, udev probably won't handle this any time soon. (Or, if it does, through some possibly clever mechanism that, as someone unfamiliar with the relevant bits of the system, I can't see.) I'd be interested in a solution to this, mostly out of curiosity since it seems like it might be interesting, but I don't see a nice one coming easily. I wouldn't mind someone more clueful telling me I'm wrong, though. At the least, it means more people being receptive to moving to udev. Matt ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 7:39 ` Matthew Reppert @ 2003-12-09 8:52 ` Måns Rullgård 2003-12-09 9:16 ` Greg KH 1 sibling, 0 replies; 103+ messages in thread From: Måns Rullgård @ 2003-12-09 8:52 UTC (permalink / raw) To: linux-kernel Matthew Reppert <repp0017@tc.umn.edu> writes: >> >From the udev FAQ: >> > >> >Q: But udev will not automatically load a driver if a /dev node is opened >> > when it is not present like devfs will do. >> >A: If you really require this functionality, then use devfs. It is still >> > present in the kernel. >> > >> >Will it have this 'equivalent functionality' some day? That's one thing I like about devfs. >> Shouldn't hotplug handle it? > > How would hotplug handle it? > > Or, more directly ... on my system, /dev is just a normal directory > on an ext2 filesystem. If something tries to open a file on it that > doesn't exist, open will just return ENOENT. How is open supposed to > know that someone is trying to open a device node? The naive solution > is to conditionally check for the presence of "/dev" at the beginning > of all requested filenames that don't exist, which strikes me as ... > well, not necessarily a good idea. (I can't really say why beyond gut > feeling.) One solution could be to make new virtual fs, say udevfs, which would be tmpfs, plus it would run modprobe when you try to open missing files. Then again, maybe I've missed something that makes this a bad idea. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 7:39 ` Matthew Reppert 2003-12-09 8:52 ` Måns Rullgård @ 2003-12-09 9:16 ` Greg KH 2003-12-09 9:45 ` Måns Rullgård 1 sibling, 1 reply; 103+ messages in thread From: Greg KH @ 2003-12-09 9:16 UTC (permalink / raw) To: Matthew Reppert; +Cc: Bob, linux-kernel, witukind On Tue, Dec 09, 2003 at 01:39:56AM -0600, Matthew Reppert wrote: > > My guess is, unfortunately, udev probably won't handle this any time > soon. (Or, if it does, through some possibly clever mechanism that, as > someone unfamiliar with the relevant bits of the system, I can't see.) udev will never handle it. That's not its job. > I'd be interested in a solution to this, mostly out of curiosity since > it seems like it might be interesting, but I don't see a nice one coming > easily. I wouldn't mind someone more clueful telling me I'm wrong, > though. At the least, it means more people being receptive to moving > to udev. Solution for a problem that is non-existant on a properly configured system? Why? :) greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:16 ` Greg KH @ 2003-12-09 9:45 ` Måns Rullgård 0 siblings, 0 replies; 103+ messages in thread From: Måns Rullgård @ 2003-12-09 9:45 UTC (permalink / raw) To: linux-kernel Greg KH <greg@kroah.com> writes: >> I'd be interested in a solution to this, mostly out of curiosity since >> it seems like it might be interesting, but I don't see a nice one coming >> easily. I wouldn't mind someone more clueful telling me I'm wrong, >> though. At the least, it means more people being receptive to moving >> to udev. > > Solution for a problem that is non-existant on a properly configured > system? Why? :) Apparently, there are people that want the functionality. Besides, why was it introduced in the first place, if not as a solution to some problem or other? -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 7:21 ` Bob 2003-12-09 7:39 ` Matthew Reppert @ 2003-12-09 9:18 ` Greg KH 2003-12-09 9:46 ` Andreas Jellinghaus 2 siblings, 0 replies; 103+ messages in thread From: Greg KH @ 2003-12-09 9:18 UTC (permalink / raw) To: Bob; +Cc: linux-kernel On Tue, Dec 09, 2003 at 02:21:11AM -0500, Bob wrote: > > hotplug and udev and sysfsutils are together at > http://www.kernel.org/pub/linux/utils/kernel/hotplug > so hotplug is part of the sysfs and udev program. No. udev uses the /sbin/hotplug notifier to do its work. udev uses libsysfs (what is under sysfsutils) to access sysfs easier, instead of making me muck around in sysfs directly. sysfsutils has nothing to do with /sbin/hotplug. greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 7:21 ` Bob 2003-12-09 7:39 ` Matthew Reppert 2003-12-09 9:18 ` Greg KH @ 2003-12-09 9:46 ` Andreas Jellinghaus 2003-12-09 10:25 ` Måns Rullgård 2 siblings, 1 reply; 103+ messages in thread From: Andreas Jellinghaus @ 2003-12-09 9:46 UTC (permalink / raw) To: linux-kernel maybe add this to the faq? Q: devfs did load drivers when someone tried to open() a non existing device. will sysfs/hotplug/udev do this? A: there is no need to. hotplug/sysfs/udev will create devices for all hardware supported by the kernel and the available modules. it will do that during boot up, and whenever new hardware is added. so you can expect all devices be already present, no need for a devfs like mechanism. Q: but what if a device is still missing? A: in that case neither the linux kernel nor the available modules support that hardware, so there is nothing hotplug/sysfs/udev can do about it. If you add modules and [FIXME: how to update the module maps] and [FIXME: remove and attach again or do ... to spawn hotplug events] the kernel will load the modules and udev will create the device files. Andreas ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:46 ` Andreas Jellinghaus @ 2003-12-09 10:25 ` Måns Rullgård 2003-12-09 15:28 ` Andreas Jellinghaus 2003-12-09 20:16 ` Oliver Hunt 0 siblings, 2 replies; 103+ messages in thread From: Måns Rullgård @ 2003-12-09 10:25 UTC (permalink / raw) To: linux-kernel Andreas Jellinghaus <aj@dungeon.inka.de> writes: > maybe add this to the faq? > > Q: devfs did load drivers when someone tried to open() a non existing > device. will sysfs/hotplug/udev do this? > > A: there is no need to. I never like it when the answer is "you don't want to do this". It makes me think of a certain Redmond based company. > hotplug/sysfs/udev will create devices for all hardware supported by > the kernel and the available modules. it will do that during boot > up, and whenever new hardware is added. so you can expect all > devices be already present, no need for a devfs like mechanism. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 10:25 ` Måns Rullgård @ 2003-12-09 15:28 ` Andreas Jellinghaus 2003-12-09 20:16 ` Oliver Hunt 1 sibling, 0 replies; 103+ messages in thread From: Andreas Jellinghaus @ 2003-12-09 15:28 UTC (permalink / raw) To: linux-kernel On Tue, 09 Dec 2003 10:29:05 +0000, Måns Rullgård wrote: > Andreas Jellinghaus <aj@dungeon.inka.de> writes: > >> maybe add this to the faq? >> >> Q: devfs did load drivers when someone tried to open() a non existing >> device. will sysfs/hotplug/udev do this? >> >> A: there is no need to. > > I never like it when the answer is "you don't want to do this". It > makes me think of a certain Redmond based company. ok, rephrase: A: all drivers are already loaded via the hotplug mechanism, and sysfs/udev did create the device. If it is still missing, you don't have drivers for your hardware. better? Andreas ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 10:25 ` Måns Rullgård 2003-12-09 15:28 ` Andreas Jellinghaus @ 2003-12-09 20:16 ` Oliver Hunt 2003-12-09 20:53 ` Måns Rullgård 1 sibling, 1 reply; 103+ messages in thread From: Oliver Hunt @ 2003-12-09 20:16 UTC (permalink / raw) To: Måns Rullgård, linux-kernel Måns Rullgård wrote: > Andreas Jellinghaus <aj@dungeon.inka.de> writes: > > >>maybe add this to the faq? >> >>Q: devfs did load drivers when someone tried to open() a non existing >>device. will sysfs/hotplug/udev do this? >> >>A: there is no need to. > > > I never like it when the answer is "you don't want to do this". It > makes me think of a certain Redmond based company. > > >>hotplug/sysfs/udev will create devices for all hardware supported by >>the kernel and the available modules. it will do that during boot >>up, and whenever new hardware is added. so you can expect all >>devices be already present, no need for a devfs like mechanism. > > No... that's MacOS.. it does everything you want it to do... if you think otherwise, you're *wrong*, although this isn't as applicable in MacOS X... --Oliver PS not meant to offend MacOS users... ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 20:16 ` Oliver Hunt @ 2003-12-09 20:53 ` Måns Rullgård 2003-12-09 22:14 ` Olaf Hering 2003-12-09 22:46 ` Oliver Hunt 0 siblings, 2 replies; 103+ messages in thread From: Måns Rullgård @ 2003-12-09 20:53 UTC (permalink / raw) To: linux-kernel Oliver Hunt <ojh16@student.canterbury.ac.nz> writes: > Måns Rullgård wrote: > >> Andreas Jellinghaus <aj@dungeon.inka.de> writes: >> >>>maybe add this to the faq? >>> >>>Q: devfs did load drivers when someone tried to open() a non existing >>>device. will sysfs/hotplug/udev do this? >>> >>>A: there is no need to. >> >> I never like it when the answer is "you don't want to do this". It >> makes me think of a certain Redmond based company. >> > No... that's MacOS.. it does everything you want it to do... if you > think otherwise, you're *wrong*, Quite true, I've never been able to use the old MacOS for more than a few minutes without a total system crash, only fixable by pulling the plug. MacOS is right, I don't want to use it, and it didn't let me. Perfect. > although this isn't as applicable in MacOS X... It didn't crash, but it made me log out very quickly. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 20:53 ` Måns Rullgård @ 2003-12-09 22:14 ` Olaf Hering 2003-12-09 22:46 ` Oliver Hunt 1 sibling, 0 replies; 103+ messages in thread From: Olaf Hering @ 2003-12-09 22:14 UTC (permalink / raw) To: linux-kernel On Tue, Dec 09, Måns Rullgård wrote: > Quite true, I've never been able to use the old MacOS for more than a > few minutes without a total system crash, only fixable by pulling the > plug. MacOS is right, I don't want to use it, and it didn't let me. > Perfect. you need almost 4 lines to say 'I should better not use a computer.'? -- USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 20:53 ` Måns Rullgård 2003-12-09 22:14 ` Olaf Hering @ 2003-12-09 22:46 ` Oliver Hunt 2003-12-09 23:03 ` Måns Rullgård 1 sibling, 1 reply; 103+ messages in thread From: Oliver Hunt @ 2003-12-09 22:46 UTC (permalink / raw) To: Måns Rullgård, linux-kernel Måns Rullgård wrote: > Oliver Hunt <ojh16@student.canterbury.ac.nz> writes: > > >>Måns Rullgård wrote: >> >> >>>Andreas Jellinghaus <aj@dungeon.inka.de> writes: >>> >>> >>>>maybe add this to the faq? >>>> >>>>Q: devfs did load drivers when someone tried to open() a non existing >>>>device. will sysfs/hotplug/udev do this? >>>> >>>>A: there is no need to. >>> >>>I never like it when the answer is "you don't want to do this". It >>>makes me think of a certain Redmond based company. >>> >> >>No... that's MacOS.. it does everything you want it to do... if you >>think otherwise, you're *wrong*, > > > Quite true, I've never been able to use the old MacOS for more than a > few minutes without a total system crash, only fixable by pulling the > plug. MacOS is right, I don't want to use it, and it didn't let me. > Perfect. > > >>although this isn't as applicable in MacOS X... > > > It didn't crash, but it made me log out very quickly. > I'm currently doing development under macos x, and have come to the conclusion that macos does some things well, others, not so well... There's certainly a lot that can be learned from it (sometimes we can learn what not to do -- The dock would be a good example of this :) ) --Oliver ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 22:46 ` Oliver Hunt @ 2003-12-09 23:03 ` Måns Rullgård 0 siblings, 0 replies; 103+ messages in thread From: Måns Rullgård @ 2003-12-09 23:03 UTC (permalink / raw) To: linux-kernel Oliver Hunt <ojh16@student.canterbury.ac.nz> writes: > Måns Rullgård wrote: > >> Oliver Hunt <ojh16@student.canterbury.ac.nz> writes: >> >>>although this isn't as applicable in MacOS X... >> It didn't crash, but it made me log out very quickly. >> > I'm currently doing development under macos x, and have come to the > conclusion that macos does some things well, others, not so > well... There's certainly a lot that can be learned from it (sometimes > we can learn what not to do -- The dock would be a good example of > this :) ) MacOS X is much better than the earlier ones, if you get rid if the terrible GUI, that is. The file manager wouldn't even let me see /tmp, or a whole lot of other files. I tried to burn a CD-RW, but that failed. The problem was it already had some files on it, so macos kindly mounted it for me, and then refused to write erase a mounted disk. Enough of this ranting, though. It's off-topic. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 5:17 ` Witukind 2003-12-09 7:21 ` Bob @ 2003-12-09 7:56 ` Greg KH 2003-12-09 9:00 ` Xavier Bestel ` (2 more replies) 1 sibling, 3 replies; 103+ messages in thread From: Greg KH @ 2003-12-09 7:56 UTC (permalink / raw) To: Witukind; +Cc: recbo, linux-kernel On Tue, Dec 09, 2003 at 06:17:28AM +0100, Witukind wrote: > From the udev FAQ: > > Q: But udev will not automatically load a driver if a /dev node is opened > when it is not present like devfs will do. > A: If you really require this functionality, then use devfs. It is still > present in the kernel. > > Will it have this 'equivalent functionality' some day? Heh, no. I really don't believe all of the people who keep asking me this. I think I need to reword this answer to something like: A: That is correct. If you really require this functionality, then use devfs. There is no way that udev can support this, and it never will. That better? :) thanks, greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 7:56 ` Greg KH @ 2003-12-09 9:00 ` Xavier Bestel 2003-12-09 9:08 ` Greg KH 2003-12-09 9:26 ` Måns Rullgård 2003-12-10 8:13 ` Jakob Oestergaard 2003-12-10 8:24 ` Rob Landley 2 siblings, 2 replies; 103+ messages in thread From: Xavier Bestel @ 2003-12-09 9:00 UTC (permalink / raw) To: Greg KH; +Cc: Witukind, recbo, Linux Kernel Mailing List Le mar 09/12/2003 à 08:56, Greg KH a écrit : > A: That is correct. If you really require this functionality, then > use devfs. There is no way that udev can support this, and it > never will. That's something I don't understand: I thought that with a well configured hotplug+udev system, you'll never have to worry about loading drivers on device-node open() because all drivers should be auto-loaded and all device-nodes should be auto-created. Am I wrong ? Xav ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:00 ` Xavier Bestel @ 2003-12-09 9:08 ` Greg KH 2003-12-09 9:19 ` Miles Bader 2003-12-09 9:55 ` Xavier Bestel 2003-12-09 9:26 ` Måns Rullgård 1 sibling, 2 replies; 103+ messages in thread From: Greg KH @ 2003-12-09 9:08 UTC (permalink / raw) To: Xavier Bestel; +Cc: Witukind, recbo, Linux Kernel Mailing List On Tue, Dec 09, 2003 at 10:00:34AM +0100, Xavier Bestel wrote: > Le mar 09/12/2003 à 08:56, Greg KH a écrit : > > A: That is correct. If you really require this functionality, then > > use devfs. There is no way that udev can support this, and it > > never will. > > That's something I don't understand: I thought that with a well > configured hotplug+udev system, you'll never have to worry about loading > drivers on device-node open() because all drivers should be auto-loaded > and all device-nodes should be auto-created. > > Am I wrong ? No, you are correct. That's why I'm not really worried about this, and I don't think anyone else should be either. thanks, greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:08 ` Greg KH @ 2003-12-09 9:19 ` Miles Bader 2003-12-09 9:39 ` Måns Rullgård 2003-12-09 9:55 ` Xavier Bestel 1 sibling, 1 reply; 103+ messages in thread From: Miles Bader @ 2003-12-09 9:19 UTC (permalink / raw) To: Greg KH; +Cc: Xavier Bestel, Witukind, recbo, Linux Kernel Mailing List Greg KH <greg@kroah.com> writes: > > > A: That is correct. If you really require this functionality, then > > > use devfs. There is no way that udev can support this, and it > > > never will. > > > > That's something I don't understand: I thought that with a well > > configured hotplug+udev system, you'll never have to worry about loading > > drivers on device-node open() because all drivers should be auto-loaded > > and all device-nodes should be auto-created. > > No, you are correct. That's why I'm not really worried about this, and > I don't think anyone else should be either. Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for... -Miles -- P.S. All information contained in the above letter is false, for reasons of military security. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:19 ` Miles Bader @ 2003-12-09 9:39 ` Måns Rullgård 2003-12-09 11:01 ` Helge Hafting 2003-12-10 19:23 ` Witukind 0 siblings, 2 replies; 103+ messages in thread From: Måns Rullgård @ 2003-12-09 9:39 UTC (permalink / raw) To: linux-kernel Miles Bader <miles@lsi.nec.co.jp> writes: >> > > A: That is correct. If you really require this functionality, then >> > > use devfs. There is no way that udev can support this, and it >> > > never will. >> > >> > That's something I don't understand: I thought that with a well >> > configured hotplug+udev system, you'll never have to worry about loading >> > drivers on device-node open() because all drivers should be auto-loaded >> > and all device-nodes should be auto-created. >> >> No, you are correct. That's why I'm not really worried about this, and >> I don't think anyone else should be either. > > Is there a specific case for which people want this feature? > Offhand it seems like a slightly odd thing to ask for... I believe the original motivation for module autoloading was to save memory by unloading modules when their devices were unused. Loading them automatically on demand made for less trouble for users, who didn't have to run modprobe manually to use the sound card, or whatever. This could still be a good thing in embedded systems. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:39 ` Måns Rullgård @ 2003-12-09 11:01 ` Helge Hafting 2003-12-12 11:26 ` Jamie Lokier 2003-12-10 19:23 ` Witukind 1 sibling, 1 reply; 103+ messages in thread From: Helge Hafting @ 2003-12-09 11:01 UTC (permalink / raw) To: Måns Rullgård; +Cc: linux-kernel Måns Rullgård wrote: > Miles Bader <miles@lsi.nec.co.jp> writes: > > >>>>> A: That is correct. If you really require this functionality, then >>>>> use devfs. There is no way that udev can support this, and it >>>>> never will. >>>> >>>>That's something I don't understand: I thought that with a well >>>>configured hotplug+udev system, you'll never have to worry about loading >>>>drivers on device-node open() because all drivers should be auto-loaded >>>>and all device-nodes should be auto-created. >>> >>>No, you are correct. That's why I'm not really worried about this, and >>>I don't think anyone else should be either. >> >>Is there a specific case for which people want this feature? >>Offhand it seems like a slightly odd thing to ask for... > > > I believe the original motivation for module autoloading was to save > memory by unloading modules when their devices were unused. Loading > them automatically on demand made for less trouble for users, who > didn't have to run modprobe manually to use the sound card, or > whatever. This could still be a good thing in embedded systems. > Sure. And if you want to run this way with udev, set it up so device nodes don't get deleted when the device unloads. That way you keep device nodes for your driverless devices, and when you try to open them the kernel runs modprobe for you. Devfs isn't needed for that afaik, it is only needed for modprobing devices that doesn't have a /dev entry yet. Your /dev will contain nodes both for driven and non-driven devices, but not for devices you don't have at all. Helge Hafting ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 11:01 ` Helge Hafting @ 2003-12-12 11:26 ` Jamie Lokier 2003-12-12 13:33 ` Duncan Sands 2003-12-12 16:34 ` Chuck Campbell 0 siblings, 2 replies; 103+ messages in thread From: Jamie Lokier @ 2003-12-12 11:26 UTC (permalink / raw) To: Helge Hafting; +Cc: Måns Rullgård, linux-kernel Helge Hafting wrote: > And if you want to run this way with udev, set it up so device nodes > don't get deleted when the device unloads. That way you keep > device nodes for your driverless devices, and when you try to open > them the kernel runs modprobe for you. Devfs isn't needed for that > afaik, it is only needed for modprobing devices that doesn't have > a /dev entry yet. > > Your /dev will contain nodes both for driven and non-driven > devices, but not for devices you don't have at all. If anyone wants to do this _properly_, this is what to do: 1. Let hotplug+udev load modules and create devices as they do now. 2. Keep track of when devices are used, and when they are not busy. We already have this, it's the module reference count. 3. When a device has not been used in a while, convert it to an "inactive" state. In this state, the hardware device is made quiescent and interrupt handlers are unregistered (perhaps temporarily; the interrupt might still be claimed, but the handler must not be called). The power management hooks should be involved, as this is an ideal opportunity to power down a device to a low-power or off state, just like during APM/ACPI suspend. 4. Make module code pages _demand-pagable_ from the original place where the module was loaded when all devices using the module are in the inactive state. This forces the module file to be kept open, so demand paging may be optionally disabled allowing the underlying fs to be unmounted. This will create all the correct device entries for hardware which is permanent or plugged in whether used or not; it will remove device entries for hardware which is unplugged; it will retain state across device opens, and it will save memory. The traditional problems with making module code swappable are that swapping is not safe in critical sections like interrupt handlers, and you never know which modules are needed for swapping. The former is solved by locking the code in RAM while the devices are active and have registered interrupt handlers (or other callbacks). The latter is obviously likely with the IDE or filesystem modules, but what if I'm swapping over a multi-route network where the backup link is on-demand PPP over a software modem over my ALSA driven radio card? That last problem is not solved in general by the current /etc/modprobe.conf method of loading whole modules on demand. However any system which works with whole module demand loading, and several more, will work automatically with demand-paged modules. A demand-paged module retains a reference to the filesystem it is mounted on, and it may be generally assumed that the filesystem will stay accessible e.g. as a local disk, boot-time accessible NFS, initramfs, or even an embedded ROM. If the filesystem's underlying device or network is dependent on a module, the mount reference will ensure that device cannot enter the inactive state, so the situation of a module being paged out which is needed to page it back in won't arise, except in the most contrived situations such as modules being loaded over NFS over an on-demand network link. Even then, the failure case is well confined: the kernel's attempt to make a device "active" will fail in userspace at the point where it tried to open the device, configure the network interface or whatever else would cause a module to be demand loaded. Now that the kernel parses ELF module files itself, this idea is much more feasible than it once was. -- Jamie ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-12 11:26 ` Jamie Lokier @ 2003-12-12 13:33 ` Duncan Sands 2003-12-12 14:51 ` Jamie Lokier 2003-12-12 16:34 ` Chuck Campbell 1 sibling, 1 reply; 103+ messages in thread From: Duncan Sands @ 2003-12-12 13:33 UTC (permalink / raw) To: Jamie Lokier, Helge Hafting; +Cc: Måns Rullgård, linux-kernel > 2. Keep track of when devices are used, and when they are not busy. > We already have this, it's the module reference count. USB modules (eg: xxxx-hcd) are typically set up so they can be unloaded at any time: the act of unloading disconnects any devices driven by the module and frees resources. I guess this is problematic for your point 2. I understand that some network modules work this way too. All the best, Duncan. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-12 13:33 ` Duncan Sands @ 2003-12-12 14:51 ` Jamie Lokier 0 siblings, 0 replies; 103+ messages in thread From: Jamie Lokier @ 2003-12-12 14:51 UTC (permalink / raw) To: Duncan Sands; +Cc: Helge Hafting, Måns Rullgård, linux-kernel Duncan Sands wrote: > > 2. Keep track of when devices are used, and when they are not busy. > > We already have this, it's the module reference count. > > USB modules (eg: xxxx-hcd) are typically set up so they can be > unloaded at any time: the act of unloading disconnects any devices > driven by the module and frees resources. I guess this is > problematic for your point 2. I understand that some network > modules work this way too. I don't see a problem. A HCD device such as a keyboard is always "active" because it must always be listening for keys as long as the keyboard is plugged in. You can explicitly "soft unplug" by unloading the module; the proposal doesn't change that. (Although it would be a nice interface to copy the PCMCIA method, where you tell the USB subsystem to disconnect a device instead of having to know which module(s) to unload). I agree that in that case, the device is active regardless of its module reference count. They aren't the same thing. (Taking it further, USB keyboard is an example of a driver that could be made permanently demand-pageable as all of the code _could_ be executed in a process context, if USB's callbacks were made to work that way, but that road is potentially quite a complicated and error prone one). A network device is similar as long as its interface is up (if it's a device). A protocol module is active as long as it has any active users, for which various definitions are possible. Protocol (+ mid-layer, helper modules etc.) show that ideally the "active" property of a module includes any references to it by other active modules, which can be interpreted in a simple or a complicated way, depending on how thoroughly you want modules to be paged out while still presenting their interfaces in /sys, /dev, /proc, ifconfig, iptables etc. -- Jamie ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-12 11:26 ` Jamie Lokier 2003-12-12 13:33 ` Duncan Sands @ 2003-12-12 16:34 ` Chuck Campbell 2003-12-12 17:13 ` Chris Friesen 2003-12-12 17:17 ` Måns Rullgård 1 sibling, 2 replies; 103+ messages in thread From: Chuck Campbell @ 2003-12-12 16:34 UTC (permalink / raw) To: Jamie Lokier; +Cc: Helge Hafting, Måns Rullgård, linux-kernel On Fri, Dec 12, 2003 at 11:26:36AM +0000, Jamie Lokier wrote: > > If anyone wants to do this _properly_, this is what to do: > I might have missed something, but this is only for modular devices right? No application to devices compiled in monolithically? Is there already in place similar functionality for non-modules? -chuck -- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-12 16:34 ` Chuck Campbell @ 2003-12-12 17:13 ` Chris Friesen 2003-12-12 17:17 ` Måns Rullgård 1 sibling, 0 replies; 103+ messages in thread From: Chris Friesen @ 2003-12-12 17:13 UTC (permalink / raw) To: campbell Cc: Jamie Lokier, Helge Hafting, Måns Rullgård, linux-kernel Chuck Campbell wrote: > On Fri, Dec 12, 2003 at 11:26:36AM +0000, Jamie Lokier wrote: > >>If anyone wants to do this _properly_, this is what to do: >> >> > > I might have missed something, but this is only for modular devices right? Depends on what you mean by "this". > No application to devices compiled in monolithically? As devices are detected, hotplug is called (which then calls udev), and udev finds the new entries in /sys and adds the appropriate nodes in /dev. Completely separate from udev, the hotplug framework also loads the module if the driver is not compiled-in. Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-12 16:34 ` Chuck Campbell 2003-12-12 17:13 ` Chris Friesen @ 2003-12-12 17:17 ` Måns Rullgård 2003-12-15 2:12 ` Miles Bader 1 sibling, 1 reply; 103+ messages in thread From: Måns Rullgård @ 2003-12-12 17:17 UTC (permalink / raw) To: Chuck Campbell; +Cc: Jamie Lokier, Helge Hafting, linux-kernel Please, don't CC me. I'm subscribed to linux-kernel and don't need two copies of all mails. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-12 17:17 ` Måns Rullgård @ 2003-12-15 2:12 ` Miles Bader 2003-12-15 3:51 ` Mark Mielke 2003-12-15 6:09 ` Tim Connors 0 siblings, 2 replies; 103+ messages in thread From: Miles Bader @ 2003-12-15 2:12 UTC (permalink / raw) To: Måns Rullgård Cc: Chuck Campbell, Jamie Lokier, Helge Hafting, linux-kernel mru@kth.se (Måns Rullgård) writes: > Please, don't CC me. I'm subscribed to linux-kernel and don't need > two copies of all mails. You ought to put in one of those magic headers that says so (I don't see one in your messages, though maybe I overlooked something), as you can hardly expect everybody to remember who's subscribed to the list and who's not. [No I don't remember what they are; I don't care about duplicate replies, in fact I _like_ duplicate replies (because it means I usually get a copy faster than what goes through the list reflector).] -Miles -- We live, as we dream -- alone.... ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-15 2:12 ` Miles Bader @ 2003-12-15 3:51 ` Mark Mielke 2003-12-15 6:09 ` Tim Connors 1 sibling, 0 replies; 103+ messages in thread From: Mark Mielke @ 2003-12-15 3:51 UTC (permalink / raw) To: Miles Bader; +Cc: Måns Rullgård, linux-kernel On Mon, Dec 15, 2003 at 11:12:50AM +0900, Miles Bader wrote: > mru@kth.se (Måns Rullgård) writes: > > Please, don't CC me. I'm subscribed to linux-kernel and don't need > > two copies of all mails. > You ought to put in one of those magic headers that says so (I don't see > one in your messages, though maybe I overlooked something), as you can > hardly expect everybody to remember who's subscribed to the list and > who's not. I am also a believer that it is the sender's responsibility to communicate their wishes according to the generally accepted protocols. At the moment, I believe the most popular and implemented one is Mail-Followup-To. Set it however you want. Don't complain until you have set it. This is standard mailing list trivia, though, and so, please keep "don't CC me requests" off the mailing list. :-) My excuse for posting this is to offer Mail-Followup-To as a researching starting point, rather than let people become frustrated. Cheers, mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-15 2:12 ` Miles Bader 2003-12-15 3:51 ` Mark Mielke @ 2003-12-15 6:09 ` Tim Connors 1 sibling, 0 replies; 103+ messages in thread From: Tim Connors @ 2003-12-15 6:09 UTC (permalink / raw) To: linux-kernel Miles Bader <miles@lsi.nec.co.jp> said on 15 Dec 2003 11:12:50 +0900: > mru@kth.se (Måns Rullgård) writes: > > Please, don't CC me. I'm subscribed to linux-kernel and don't need > > two copies of all mails. > > You ought to put in one of those magic headers that says so (I don't see > one in your messages, though maybe I overlooked something), as you can > hardly expect everybody to remember who's subscribed to the list and > who's not. > > [No I don't remember what they are; I don't care about duplicate > replies, in fact I _like_ duplicate replies (because it means I usually > get a copy faster than what goes through the list reflector).] And there's always procmail: # avoid duplicate messages :0 Whc: msgid.lock | formail -D 16384 .msgid.cache :0 a: .duplicates I do further processing to make sure that any replies direct to me make it direct to me, instead of going into mailing list folder... -- TimC -- http://astronomy.swin.edu.au/staff/tconnors/ "Eddies in the space time continuum" "Oh. Is he?" -- Zem? ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:39 ` Måns Rullgård 2003-12-09 11:01 ` Helge Hafting @ 2003-12-10 19:23 ` Witukind 2003-12-10 19:33 ` Måns Rullgård 1 sibling, 1 reply; 103+ messages in thread From: Witukind @ 2003-12-10 19:23 UTC (permalink / raw) To: Måns Rullgård; +Cc: linux-kernel On Tue, 09 Dec 2003 10:39:32 +0100 mru@kth.se (Måns Rullgård) wrote: > > Is there a specific case for which people want this feature? > > Offhand it seems like a slightly odd thing to ask for... > > I believe the original motivation for module autoloading was to save > memory by unloading modules when their devices were unused. Loading > them automatically on demand made for less trouble for users, who > didn't have to run modprobe manually to use the sound card, or > whatever. This could still be a good thing in embedded systems. > I don't see why it wouldn't be a good thing for regular systems also. Saving memory is usually a good idea. -- Jabber: heimdal@jabber.org ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 19:23 ` Witukind @ 2003-12-10 19:33 ` Måns Rullgård 2003-12-10 20:22 ` Witukind 2003-12-10 23:40 ` Maciej Zenczykowski 0 siblings, 2 replies; 103+ messages in thread From: Måns Rullgård @ 2003-12-10 19:33 UTC (permalink / raw) To: linux-kernel Witukind <witukind@nsbm.kicks-ass.org> writes: > On Tue, 09 Dec 2003 10:39:32 +0100 mru@kth.se (Måns Rullgård) wrote: > >> > Is there a specific case for which people want this feature? >> > Offhand it seems like a slightly odd thing to ask for... >> >> I believe the original motivation for module autoloading was to save >> memory by unloading modules when their devices were unused. Loading >> them automatically on demand made for less trouble for users, who >> didn't have to run modprobe manually to use the sound card, or >> whatever. This could still be a good thing in embedded systems. >> > > I don't see why it wouldn't be a good thing for regular systems > also. Saving memory is usually a good idea. The biggest modules are about 100k. Saving 100k of 1 GB doesn't really seem worth any effort. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 19:33 ` Måns Rullgård @ 2003-12-10 20:22 ` Witukind 2003-12-10 20:47 ` Ed Sweetman 2003-12-10 20:48 ` Måns Rullgård 2003-12-10 23:40 ` Maciej Zenczykowski 1 sibling, 2 replies; 103+ messages in thread From: Witukind @ 2003-12-10 20:22 UTC (permalink / raw) To: Måns Rullgård; +Cc: linux-kernel On Wed, 10 Dec 2003 20:33:24 +0100 mru@kth.se (Måns Rullgård) wrote: > Witukind <witukind@nsbm.kicks-ass.org> writes: > > > On Tue, 09 Dec 2003 10:39:32 +0100 mru@kth.se (Måns Rullgård) wrote: > > > >> > Is there a specific case for which people want this feature? > >> > Offhand it seems like a slightly odd thing to ask for... > >> > >> I believe the original motivation for module autoloading was to > >save> memory by unloading modules when their devices were unused. > >Loading> them automatically on demand made for less trouble for > >users, who> didn't have to run modprobe manually to use the sound > >card, or> whatever. This could still be a good thing in embedded > >systems.> > > > > I don't see why it wouldn't be a good thing for regular systems > > also. Saving memory is usually a good idea. > > The biggest modules are about 100k. Saving 100k of 1 GB doesn't > really seem worth any effort. I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving 100k is worth the effort. -- Jabber: heimdal@jabber.org ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 20:22 ` Witukind @ 2003-12-10 20:47 ` Ed Sweetman 2003-12-10 20:53 ` Ed Sweetman ` (3 more replies) 2003-12-10 20:48 ` Måns Rullgård 1 sibling, 4 replies; 103+ messages in thread From: Ed Sweetman @ 2003-12-10 20:47 UTC (permalink / raw) To: Witukind; +Cc: Måns Rullgård, linux-kernel Witukind wrote: > On Wed, 10 Dec 2003 20:33:24 +0100 > mru@kth.se (Måns Rullgård) wrote: > > >>Witukind <witukind@nsbm.kicks-ass.org> writes: >> >> >>>On Tue, 09 Dec 2003 10:39:32 +0100 mru@kth.se (Måns Rullgård) wrote: >>> >>> >>>>>Is there a specific case for which people want this feature? >>>>>Offhand it seems like a slightly odd thing to ask for... >>>> >>>>I believe the original motivation for module autoloading was to >>> >>>save> memory by unloading modules when their devices were unused. >>>Loading> them automatically on demand made for less trouble for >>>users, who> didn't have to run modprobe manually to use the sound >>>card, or> whatever. This could still be a good thing in embedded >>>systems.> >>> the biggest advantage from modules is the ability to enable/disable devices with different initialization configurations without rebooting, including the use of devices that aren't present during boot or may be added to a system that cant be put down to reboot. Embedded systems usually do not change, that's just part of being embedded, modules dont really make sense there unless things like filesystems and non-device modules never get used at the same time and memory is limited such that 100KB actually matters. >>>I don't see why it wouldn't be a good thing for regular systems >>>also. Saving memory is usually a good idea. True, but how about we start being good memory users where it counts the most, like gui's/userspace land and then worry about the sub 1MB usage that kernels exist in. >>The biggest modules are about 100k. Saving 100k of 1 GB doesn't >>really seem worth any effort. > > > I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving 100k is worth > the effort. Then why do you use a sylpheed, which is gtk instead of something in a terminal that uses much less memory (doesn't require xfree86, which you're probably also using instead of tinyX) and toolkits, pixmaps etc. Obviously, 100k is not worth _your_ effort. I'm not saying module use is more memory efficient than not or vice versa, but if memory usage in the 100K range is going to be the only argument for autoloading/unloading of modules then it's really _not_ worth the effort unless someone can give that kind of support without trying. Your fight for memory efficiency should start where the inefficiency is the largest, and work it's way down, not the other way around. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 20:47 ` Ed Sweetman @ 2003-12-10 20:53 ` Ed Sweetman 2003-12-10 21:31 ` Witukind 2003-12-10 21:28 ` Witukind ` (2 subsequent siblings) 3 siblings, 1 reply; 103+ messages in thread From: Ed Sweetman @ 2003-12-10 20:53 UTC (permalink / raw) To: Ed Sweetman; +Cc: Witukind, Måns Rullgård, linux-kernel Ed Sweetman wrote: > Witukind wrote: > >> On Wed, 10 Dec 2003 20:33:24 +0100 >> mru@kth.se (Måns Rullgård) wrote: >> >> >>> Witukind <witukind@nsbm.kicks-ass.org> writes: >>> >>> >>>> On Tue, 09 Dec 2003 10:39:32 +0100 mru@kth.se (Måns Rullgård) wrote: >>>> >>>> >>>>>> Is there a specific case for which people want this feature? >>>>>> Offhand it seems like a slightly odd thing to ask for... >>>>> >>>>> >>>>> I believe the original motivation for module autoloading was to >>>> >>>> >>>> save> memory by unloading modules when their devices were unused. >>>> Loading> them automatically on demand made for less trouble for >>>> users, who> didn't have to run modprobe manually to use the sound >>>> card, or> whatever. This could still be a good thing in embedded >>>> systems.> > > the biggest advantage from modules is the ability to enable/disable > devices with different initialization configurations without rebooting, > including the use of devices that aren't present during boot or may be > added to a system that cant be put down to reboot. Embedded systems > usually do not change, that's just part of being embedded, modules dont > really make sense there unless things like filesystems and non-device > modules never get used at the same time and memory is limited such that > 100KB actually matters. > > >>>> I don't see why it wouldn't be a good thing for regular systems >>>> also. Saving memory is usually a good idea. > > > True, but how about we start being good memory users where it counts the > most, like gui's/userspace land and then worry about the sub 1MB usage > that kernels exist in. > >>> The biggest modules are about 100k. Saving 100k of 1 GB doesn't >>> really seem worth any effort. >> >> >> >> I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving 100k >> is worth >> the effort. > Blah, scratch this. > Then why do you use a sylpheed, which is gtk instead of something in a > terminal that uses much less memory (doesn't require xfree86, which > you're probably also using instead of tinyX) and toolkits, pixmaps etc. > Obviously, 100k is not worth _your_ effort. And of course that's all assuming you're using your laptop to write and send email. Which you probably wouldn't be doing on a 16MB laptop...probably wouldn't be doing anything on a 16MB laptop. But anyway, the rest of what i was talking about is ok. > > I'm not saying module use is more memory efficient than not or vice > versa, but if memory usage in the 100K range is going to be the only > argument for autoloading/unloading of modules then it's really _not_ > worth the effort unless someone can give that kind of support without > trying. Your fight for memory efficiency should start where the > inefficiency is the largest, and work it's way down, not the other way > around. > ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 20:53 ` Ed Sweetman @ 2003-12-10 21:31 ` Witukind 0 siblings, 0 replies; 103+ messages in thread From: Witukind @ 2003-12-10 21:31 UTC (permalink / raw) To: Ed Sweetman; +Cc: ed.sweetman, mru, linux-kernel On Wed, 10 Dec 2003 15:53:03 -0500 Ed Sweetman <ed.sweetman@wmich.edu> wrote: > Ed Sweetman wrote: > > Witukind wrote: > > > >> On Wed, 10 Dec 2003 20:33:24 +0100 > >> mru@kth.se (Måns Rullgård) wrote: > >> > >> > >>> Witukind <witukind@nsbm.kicks-ass.org> writes: > >>> > >>> > >>>> On Tue, 09 Dec 2003 10:39:32 +0100 mru@kth.se (Måns Rullgård) > >wrote:>>> > >>>> > >>>>>> Is there a specific case for which people want this feature? > >>>>>> Offhand it seems like a slightly odd thing to ask for... > >>>>> > >>>>> > >>>>> I believe the original motivation for module autoloading was to > >>>> > >>>> > >>>> save> memory by unloading modules when their devices were unused. > > > >>>> Loading> them automatically on demand made for less trouble for > >>>> users, who> didn't have to run modprobe manually to use the sound > >>>> card, or> whatever. This could still be a good thing in embedded > >>>> systems.> > > > > the biggest advantage from modules is the ability to enable/disable > > devices with different initialization configurations without > > rebooting, including the use of devices that aren't present during > > boot or may be added to a system that cant be put down to reboot. > > Embedded systems usually do not change, that's just part of being > > embedded, modules dont really make sense there unless things like > > filesystems and non-device modules never get used at the same time > > and memory is limited such that 100KB actually matters. > > > > > >>>> I don't see why it wouldn't be a good thing for regular systems > >>>> also. Saving memory is usually a good idea. > > > > > > True, but how about we start being good memory users where it counts > > the most, like gui's/userspace land and then worry about the sub 1MB > > usage that kernels exist in. > > > >>> The biggest modules are about 100k. Saving 100k of 1 GB doesn't > >>> really seem worth any effort. > >> > >> > >> > >> I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving > >100k > is worth > >> the effort. > > > > Blah, scratch this. > > Then why do you use a sylpheed, which is gtk instead of something in > > a terminal that uses much less memory (doesn't require xfree86, > > which you're probably also using instead of tinyX) and toolkits, > > pixmaps etc. > > Obviously, 100k is not worth _your_ effort. > > And of course that's all assuming you're using your laptop to write > and send email. Which you probably wouldn't be doing on a 16MB > laptop...probably wouldn't be doing anything on a 16MB laptop. But > anyway, the rest of what i was talking about is ok. Well you can do a lot of things on this laptop and Wingdows 95, although I'd prefer to be able to do as much or even more using Linux with it. -- Jabber: heimdal@jabber.org ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 20:47 ` Ed Sweetman 2003-12-10 20:53 ` Ed Sweetman @ 2003-12-10 21:28 ` Witukind 2003-12-10 21:48 ` Måns Rullgård 2003-12-10 21:49 ` Måns Rullgård 2003-12-10 23:48 ` Maciej Zenczykowski 3 siblings, 1 reply; 103+ messages in thread From: Witukind @ 2003-12-10 21:28 UTC (permalink / raw) To: Ed Sweetman; +Cc: mru, linux-kernel On Wed, 10 Dec 2003 15:47:01 -0500 Ed Sweetman <ed.sweetman@wmich.edu> wrote: > Witukind wrote: > > On Wed, 10 Dec 2003 20:33:24 +0100 > > mru@kth.se (Måns Rullgård) wrote: > > > > > >>Witukind <witukind@nsbm.kicks-ass.org> writes: > >> > >> > >>>On Tue, 09 Dec 2003 10:39:32 +0100 mru@kth.se (Måns Rullgård) > >wrote:>> > >>> > >>>>>Is there a specific case for which people want this feature? > >>>>>Offhand it seems like a slightly odd thing to ask for... > >>>> > >>>>I believe the original motivation for module autoloading was to > >>> > >>>save> memory by unloading modules when their devices were unused. > >>>Loading> them automatically on demand made for less trouble for > >>>users, who> didn't have to run modprobe manually to use the sound > >>>card, or> whatever. This could still be a good thing in embedded > >>>systems.> > >>> > the biggest advantage from modules is the ability to enable/disable > devices with different initialization configurations without > rebooting, including the use of devices that aren't present during > boot or may be added to a system that cant be put down to reboot. > Embedded systems usually do not change, that's just part of being > embedded, modules dont really make sense there unless things like > filesystems and non-device modules never get used at the same time and > memory is limited such that 100KB actually matters. > > > >>>I don't see why it wouldn't be a good thing for regular systems > >>>also. Saving memory is usually a good idea. > > True, but how about we start being good memory users where it counts > the most, like gui's/userspace land and then worry about the sub 1MB > usage that kernels exist in. > > >>The biggest modules are about 100k. Saving 100k of 1 GB doesn't > >>really seem worth any effort. > > > > > > I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving 100k > > is worth the effort. > > Then why do you use a sylpheed, which is gtk instead of something in a > > terminal that uses much less memory (doesn't require xfree86, which > you're probably also using instead of tinyX) and toolkits, pixmaps > etc. > Obviously, 100k is not worth _your_ effort. > > > I'm not saying module use is more memory efficient than not or vice > versa, but if memory usage in the 100K range is going to be the only > argument for autoloading/unloading of modules then it's really _not_ > worth the effort unless someone can give that kind of support without > trying. Your fight for memory efficiency should start where the > inefficiency is the largest, and work it's way down, not the other way > > around. > > > Well first of all, how do you know I am using the laptop right now? I don't use X on it actually, not even tinyX (anyway the video card is not supported by XFree86). Secondly what if I don't like text mode or the available text mode email clients? The thing is I want to get the most out of my hardware, so every opportunity to decrease RAM usage, CPU cycles and increase the speed and responsiveness is good. I do agree with you that there is much bloat in Gtk (especially 2.x). The thing is also it's not just ONE module. -- Jabber: heimdal@jabber.org ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 21:28 ` Witukind @ 2003-12-10 21:48 ` Måns Rullgård 2003-12-11 6:31 ` Witukind 0 siblings, 1 reply; 103+ messages in thread From: Måns Rullgård @ 2003-12-10 21:48 UTC (permalink / raw) To: Witukind; +Cc: Ed Sweetman, linux-kernel Witukind <witukind@nsbm.kicks-ass.org> writes: [about memory used by modules] > The thing is also it's not just ONE module. The total size of all modules loaded on my laptop right now (31 in all) is 960k. Not much of a save compared to the total 640 MB. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 21:48 ` Måns Rullgård @ 2003-12-11 6:31 ` Witukind 0 siblings, 0 replies; 103+ messages in thread From: Witukind @ 2003-12-11 6:31 UTC (permalink / raw) To: Måns Rullgård; +Cc: ed.sweetman, linux-kernel On Wed, 10 Dec 2003 22:48:31 +0100 mru@kth.se (Måns Rullgård) wrote: > Witukind <witukind@nsbm.kicks-ass.org> writes: > > [about memory used by modules] > > > The thing is also it's not just ONE module. > > The total size of all modules loaded on my laptop right now (31 in > all) is 960k. Not much of a save compared to the total 640 MB. It depends on which system. I have more than 31 (more like 50-60) useful modules even on the laptop. But anyway, in general any amount of saved RAM is good. It's a question of efficiency. -- Jabber: heimdal@jabber.org ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 20:47 ` Ed Sweetman 2003-12-10 20:53 ` Ed Sweetman 2003-12-10 21:28 ` Witukind @ 2003-12-10 21:49 ` Måns Rullgård 2003-12-10 23:48 ` Maciej Zenczykowski 3 siblings, 0 replies; 103+ messages in thread From: Måns Rullgård @ 2003-12-10 21:49 UTC (permalink / raw) To: Ed Sweetman; +Cc: Witukind, linux-kernel Ed Sweetman <ed.sweetman@wmich.edu> writes: > the biggest advantage from modules is the ability to enable/disable > devices with different initialization configurations without > rebooting, including the use of devices that aren't present during > boot or may be added to a system that cant be put down to > reboot. Embedded systems usually do not change, that's just part of > being embedded, modules dont really make sense there unless things > like filesystems and non-device modules never get used at the same > time and memory is limited such that 100KB actually matters. An embedded system could still have USB or something like that. Many PDAs do have pluggable hardware modules. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 20:47 ` Ed Sweetman ` (2 preceding siblings ...) 2003-12-10 21:49 ` Måns Rullgård @ 2003-12-10 23:48 ` Maciej Zenczykowski 2003-12-11 1:53 ` Mark Mielke 3 siblings, 1 reply; 103+ messages in thread From: Maciej Zenczykowski @ 2003-12-10 23:48 UTC (permalink / raw) To: Ed Sweetman; +Cc: Witukind, Måns Rullgård, linux-kernel > I'm not saying module use is more memory efficient than not or vice > versa, but if memory usage in the 100K range is going to be the only > argument for autoloading/unloading of modules then it's really _not_ > worth the effort unless someone can give that kind of support without > trying. Your fight for memory efficiency should start where the > inefficiency is the largest, and work it's way down, not the other way > around. That's not quite true - all kernel memory is statically mapped into ram and unswappable. 2 MB's of X will likely end up 80% swapped to disk and the rest is in use (and can still be swapped out when no longer needed). 100KB of an unused driver will not get swapped out. That's where the difference is. As for using small userspace? I do, djbdns for dns, twm for window manager etc etc... Cheers, MaZe. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 23:48 ` Maciej Zenczykowski @ 2003-12-11 1:53 ` Mark Mielke 2003-12-11 8:42 ` Måns Rullgård 0 siblings, 1 reply; 103+ messages in thread From: Mark Mielke @ 2003-12-11 1:53 UTC (permalink / raw) To: Maciej Zenczykowski Cc: Ed Sweetman, Witukind, Måns Rullgård, linux-kernel On Thu, Dec 11, 2003 at 12:48:35AM +0100, Maciej Zenczykowski wrote: > > I'm not saying module use is more memory efficient than not or vice > > versa, but if memory usage in the 100K range is going to be the only > > argument for autoloading/unloading of modules then it's really _not_ > > worth the effort unless someone can give that kind of support without > > trying. Your fight for memory efficiency should start where the > > inefficiency is the largest, and work it's way down, not the other way > > around. > That's not quite true - all kernel memory is statically mapped into ram > and unswappable. 2 MB's of X will likely end up 80% swapped to disk and > the rest is in use (and can still be swapped out when no longer needed). > 100KB of an unused driver will not get swapped out. > That's where the difference is. As for using small userspace? I do, > djbdns for dns, twm for window manager etc etc... I was under the impression, that on the x86 processors, it is not possible to have more than ~640Kb of 'unswappable' memory. Everything else *is* swappable. Perhaps somebody with understanding could enlighten us on this point? Is kernel code swappable if compiled in statically? I have assumed that it is. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-11 1:53 ` Mark Mielke @ 2003-12-11 8:42 ` Måns Rullgård 2003-12-11 16:33 ` Mark Mielke 0 siblings, 1 reply; 103+ messages in thread From: Måns Rullgård @ 2003-12-11 8:42 UTC (permalink / raw) To: linux-kernel Mark Mielke <mark@mark.mielke.cc> writes: > I was under the impression, that on the x86 processors, it is not > possible to have more than ~640Kb of 'unswappable' > memory. Everything else *is* swappable. Swappable or not doesn't depend on physical memory address. It depends on whether the kernel memory management allows it or not. No Linux kernels to date will swap out kernel memory. The swappability of a page is determined by some flags when it is allocated. > Perhaps somebody with understanding could enlighten us on this point? > > Is kernel code swappable if compiled in statically? I have assumed > that it is. That's not the way it works. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-11 8:42 ` Måns Rullgård @ 2003-12-11 16:33 ` Mark Mielke 0 siblings, 0 replies; 103+ messages in thread From: Mark Mielke @ 2003-12-11 16:33 UTC (permalink / raw) To: Måns Rullgård; +Cc: linux-kernel On Thu, Dec 11, 2003 at 09:42:21AM +0100, Måns Rullgård wrote: > Mark Mielke <mark@mark.mielke.cc> writes: > > I was under the impression, that on the x86 processors, it is not > > possible to have more than ~640Kb of 'unswappable' > > memory. Everything else *is* swappable. > Swappable or not doesn't depend on physical memory address. It > depends on whether the kernel memory management allows it or not. No > Linux kernels to date will swap out kernel memory. The swappability > of a page is determined by some flags when it is allocated. Is this something that should be fixed? Or is this a related issue where the perceived gain is small enough that it isn't worth tackling, or modules is the recommended and desirable solution to this problem? Is Microsoft Windows different in this regard? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 20:22 ` Witukind 2003-12-10 20:47 ` Ed Sweetman @ 2003-12-10 20:48 ` Måns Rullgård 1 sibling, 0 replies; 103+ messages in thread From: Måns Rullgård @ 2003-12-10 20:48 UTC (permalink / raw) To: linux-kernel Witukind <witukind@nsbm.kicks-ass.org> writes: > On Wed, 10 Dec 2003 20:33:24 +0100 > mru@kth.se (Måns Rullgård) wrote: > >> Witukind <witukind@nsbm.kicks-ass.org> writes: >> >> > On Tue, 09 Dec 2003 10:39:32 +0100 mru@kth.se (Måns Rullgård) wrote: >> > >> >> > Is there a specific case for which people want this feature? >> >> > Offhand it seems like a slightly odd thing to ask for... >> >> >> >> I believe the original motivation for module autoloading was to >> >save> memory by unloading modules when their devices were unused. >> >Loading> them automatically on demand made for less trouble for >> >users, who> didn't have to run modprobe manually to use the sound >> >card, or> whatever. This could still be a good thing in embedded >> >systems.> >> > >> > I don't see why it wouldn't be a good thing for regular systems >> > also. Saving memory is usually a good idea. >> >> The biggest modules are about 100k. Saving 100k of 1 GB doesn't >> really seem worth any effort. > > I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving 100k > is worth the effort. In that case I don't classify your laptop as a regular system any more. I remember saying that the space saving could be worthwhile on small systems a while back. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 19:33 ` Måns Rullgård 2003-12-10 20:22 ` Witukind @ 2003-12-10 23:40 ` Maciej Zenczykowski 1 sibling, 0 replies; 103+ messages in thread From: Maciej Zenczykowski @ 2003-12-10 23:40 UTC (permalink / raw) To: Måns Rullgård; +Cc: linux-kernel > > I don't see why it wouldn't be a good thing for regular systems > > also. Saving memory is usually a good idea. > > The biggest modules are about 100k. Saving 100k of 1 GB doesn't > really seem worth any effort. so let's cut kernel module support period and make the kernel fully monolithic. this will also solve the binary module vs gpl issue and everyone will be happy... cheers, maze. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:08 ` Greg KH 2003-12-09 9:19 ` Miles Bader @ 2003-12-09 9:55 ` Xavier Bestel 2003-12-09 13:03 ` Maciej Zenczykowski 2003-12-10 0:38 ` Greg KH 1 sibling, 2 replies; 103+ messages in thread From: Xavier Bestel @ 2003-12-09 9:55 UTC (permalink / raw) To: Greg KH; +Cc: Witukind, recbo, Linux Kernel Mailing List Le mar 09/12/2003 à 10:08, Greg KH a écrit : > > That's something I don't understand: I thought that with a well > > configured hotplug+udev system, you'll never have to worry about loading > > drivers on device-node open() because all drivers should be auto-loaded > > and all device-nodes should be auto-created. > > > > Am I wrong ? > > No, you are correct. That's why I'm not really worried about this, and > I don't think anyone else should be either. So to attenuate people's worries it should be stated in some form: A: Such a functionality isn't needed on a properly configured system. All devices present on the system should generate hotplug events, loading the appropriate driver, and udev should notice and create the appropriate device node. In case of failure, please make a proper bug report. Of course, you'll have to translate it to correct english. Xav ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:55 ` Xavier Bestel @ 2003-12-09 13:03 ` Maciej Zenczykowski 2003-12-09 15:01 ` Helge Hafting 2003-12-09 18:30 ` Greg KH 2003-12-10 0:38 ` Greg KH 1 sibling, 2 replies; 103+ messages in thread From: Maciej Zenczykowski @ 2003-12-09 13:03 UTC (permalink / raw) To: Xavier Bestel; +Cc: Greg KH, Witukind, recbo, Linux Kernel Mailing List > > > Am I wrong ? > > No, you are correct. That's why I'm not really worried about this, and > > I don't think anyone else should be either. You are of course totally wrong - just because a device is present in the system doesn't mean that it's kernel modules are loaded - for example my floppy is always present in the system, but I access it like once a month or so - currently devfs (which I'm using on 3 computers with no problems for over a year now) will load the floppy module on access to /dev/fd0 and the module will unload automatically a few dozen minutes later after I'm done with the disk drive. On an 8 MB mem system keeping 60KB floppy driver non-stop in unswappable kernel memory is wastefull. Especially since this also applies to microcode, sound drivers, scanners, rtc, etc... The system is properly configured - the modules for devices are loaded when needed - just because a device is present doesn't mean we need to have the driver loaded for it. > A: Such a functionality isn't needed on a properly configured > system. All devices present on the system should generate > hotplug events, loading the appropriate driver, and udev > should notice and create the appropriate device node. > In case of failure, please make a proper bug report. Cheers, MaZe. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 13:03 ` Maciej Zenczykowski @ 2003-12-09 15:01 ` Helge Hafting 2003-12-09 18:30 ` Greg KH 1 sibling, 0 replies; 103+ messages in thread From: Helge Hafting @ 2003-12-09 15:01 UTC (permalink / raw) To: Maciej Zenczykowski Cc: Xavier Bestel, Greg KH, Witukind, recbo, Linux Kernel Mailing List Maciej Zenczykowski wrote: >>>>Am I wrong ? > > >>>No, you are correct. That's why I'm not really worried about this, and >>>I don't think anyone else should be either. > > > You are of course totally wrong - just because a device is present in the > system doesn't mean that it's kernel modules are loaded - for example my > floppy is always present in the system, but I access it like once a month > or so - currently devfs (which I'm using on 3 computers with no problems > for over a year now) will load the floppy module on access to /dev/fd0 and > the module will unload automatically a few dozen minutes later after I'm > done with the disk drive. On an 8 MB mem system keeping 60KB floppy > driver non-stop in unswappable kernel memory is wastefull. Especially > since this also applies to microcode, sound drivers, scanners, rtc, etc... > The system is properly configured - the modules for devices are loaded > when needed - just because a device is present doesn't mean we need to > have the driver loaded for it. Sure, the driver doesn't need to be present all the time. If you want to use it occationally you need some kind of "trigger" to demand-load it. With devfs, this trigger mechanism is devfs+devfsd and its configuration. Devfs will notice that you're opening a nonexistant node, tell devfsd do do something, devfsd will see that you have specified module loading, do that, and then the suddenly present node is loaded. The approach without devfs is to have the device node present wheter or not the device is there. (i.e. /dev on ext2) You don't need a /dev full of all the nodes makedev creates, but you need nodes for devices you actually have. Set up udev so it don't delete nodes (or at least not the floppy node) when the driver go away. You now have a permanent floppy device. Trying to access it when it isn't there will cause the kernel itself to run modprobe, if you configured "automatic module loading". So, you can demand-load devices without devfs, you just need the device node. It wastes little disk space and no memory (unless you put your udev-managed /dev in tmpfs. But then the memory loss is quite small and the disk loss nonexistant.) You can probably have udev help you set up the device nodes, configure so nodes aren't deleted and load all your modules. udev populates /dev and that job is done. Compare to the devfs approach: It too uses memory (for devfs and devfsd, as well as disk space for devfsd.conf. And there is one disadvantage, a program cannot look in /dev to see what devices you have when the module isn't loaded. A program looking for floppy or sound devices won't find any with devfs+modules, but will find the device if you're using udev+modules. And then the driver will load when opened. Helge Hafting ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 13:03 ` Maciej Zenczykowski 2003-12-09 15:01 ` Helge Hafting @ 2003-12-09 18:30 ` Greg KH 2003-12-09 18:53 ` Måns Rullgård 1 sibling, 1 reply; 103+ messages in thread From: Greg KH @ 2003-12-09 18:30 UTC (permalink / raw) To: Maciej Zenczykowski Cc: Xavier Bestel, Witukind, recbo, Linux Kernel Mailing List On Tue, Dec 09, 2003 at 02:03:42PM +0100, Maciej Zenczykowski wrote: > > > > Am I wrong ? > > > > No, you are correct. That's why I'm not really worried about this, and > > > I don't think anyone else should be either. > > You are of course totally wrong Oh, ok. I'll just go back to writing code instead of arguing... > - just because a device is present in the system doesn't mean that > it's kernel modules are loaded No, but one could argue that it should :) > - for example my floppy is always present in the system, but I access > it like once a month or so Then, when you want to access it, a simple 'modprobe floppy' would work for you, right? Anyway, I'm not going to drag this thread out anymore. If you want to use devfs, do it. Just realize that it is an obsolete kernel feature and is marked for probable removal in 2.7. It also has known bad problems that could cause your machine to lock up. Use it at your own risk, you have been warned... greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 18:30 ` Greg KH @ 2003-12-09 18:53 ` Måns Rullgård 2003-12-10 7:02 ` Xavier Bestel 0 siblings, 1 reply; 103+ messages in thread From: Måns Rullgård @ 2003-12-09 18:53 UTC (permalink / raw) To: linux-kernel Greg KH <greg@kroah.com> writes: > On Tue, Dec 09, 2003 at 02:03:42PM +0100, Maciej Zenczykowski wrote: > >> - just because a device is present in the system doesn't mean that >> it's kernel modules are loaded > > No, but one could argue that it should :) One could equally well argue that it need not. >> - for example my floppy is always present in the system, but I access >> it like once a month or so > > Then, when you want to access it, a simple 'modprobe floppy' would work > for you, right? Only if you are root. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 18:53 ` Måns Rullgård @ 2003-12-10 7:02 ` Xavier Bestel 2003-12-10 20:06 ` Witukind 0 siblings, 1 reply; 103+ messages in thread From: Xavier Bestel @ 2003-12-10 7:02 UTC (permalink / raw) To: Måns Rullgård; +Cc: Linux Kernel Mailing List Le mar 09/12/2003 à 19:53, Måns Rullgård a écrit : > >> - for example my floppy is always present in the system, but I access > >> it like once a month or so > > > > Then, when you want to access it, a simple 'modprobe floppy' would work > > for you, right? > > Only if you are root. Come on ... the stock kernel from your distribution will do the modprobe for you when you access the floppy, I'm sure you're skilled enough to configure your own kernel to do the same. And if you don't want to recompile, just chmod +s modprobe - on your small machine which needs to save 60k, I bet you're the only user. Or use sudo. Xav ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 7:02 ` Xavier Bestel @ 2003-12-10 20:06 ` Witukind 2003-12-11 9:27 ` Xavier Bestel 0 siblings, 1 reply; 103+ messages in thread From: Witukind @ 2003-12-10 20:06 UTC (permalink / raw) To: Xavier Bestel; +Cc: mru, linux-kernel On Wed, 10 Dec 2003 08:02:46 +0100 Xavier Bestel <xavier.bestel@free.fr> wrote: > Le mar 09/12/2003 à 19:53, Måns Rullgård a écrit : > > >> - for example my floppy is always present in the system, but I > > >access> it like once a month or so > > > > > > Then, when you want to access it, a simple 'modprobe floppy' would > > > work for you, right? > > > > Only if you are root. > > Come on ... the stock kernel from your distribution will do the > modprobe for you when you access the floppy, I'm sure you're skilled > enough to configure your own kernel to do the same. > And if you don't want to recompile, just chmod +s modprobe - on your > small machine which needs to save 60k, I bet you're the only user. Or > use sudo. > > Xav I was expecting this kind of reply. Like "if you have an older hardware you can fuck off". -- Jabber: heimdal@jabber.org ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-10 20:06 ` Witukind @ 2003-12-11 9:27 ` Xavier Bestel 2003-12-11 10:15 ` Måns Rullgård 0 siblings, 1 reply; 103+ messages in thread From: Xavier Bestel @ 2003-12-11 9:27 UTC (permalink / raw) To: Witukind; +Cc: mru, Linux Kernel Mailing List Le mer 10/12/2003 à 21:06, Witukind a écrit : > On Wed, 10 Dec 2003 08:02:46 +0100 > Xavier Bestel <xavier.bestel@free.fr> wrote: > > Come on ... the stock kernel from your distribution will do the > > modprobe for you when you access the floppy, I'm sure you're skilled > > enough to configure your own kernel to do the same. > > And if you don't want to recompile, just chmod +s modprobe - on your > > small machine which needs to save 60k, I bet you're the only user. Or > > use sudo. > > > > Xav > > I was expecting this kind of reply. Like "if you have an older hardware you > can fuck off". Wow ... how can you understand this in my text ? Because I'm guessing he is the only user on his machine ? This has nothing to do with small machines, but with system configuration: load on-demand may be done without devfs. Well, I wish do apologize to Måns if he thought I was ridiculing his hardware. Just take out the last sentence with "modprobe" if it bothers you. Xav ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-11 9:27 ` Xavier Bestel @ 2003-12-11 10:15 ` Måns Rullgård 2003-12-11 11:05 ` Xavier Bestel 0 siblings, 1 reply; 103+ messages in thread From: Måns Rullgård @ 2003-12-11 10:15 UTC (permalink / raw) To: linux-kernel Xavier Bestel <xavier.bestel@free.fr> writes: > Le mer 10/12/2003 à 21:06, Witukind a écrit : >> On Wed, 10 Dec 2003 08:02:46 +0100 >> Xavier Bestel <xavier.bestel@free.fr> wrote: >> > Come on ... the stock kernel from your distribution will do the >> > modprobe for you when you access the floppy, I'm sure you're skilled >> > enough to configure your own kernel to do the same. >> > And if you don't want to recompile, just chmod +s modprobe - on your >> > small machine which needs to save 60k, I bet you're the only user. Or >> > use sudo. >> > >> > Xav >> >> I was expecting this kind of reply. Like "if you have an older hardware you >> can fuck off". > > Wow ... how can you understand this in my text ? Because I'm guessing he > is the only user on his machine ? This has nothing to do with small > machines, but with system configuration: load on-demand may be done > without devfs. It certainly can be done without devfs. I was objecting to the udev way of thinking that all drivers are always loaded. If you want to use udev and on-demand loading, you need to do some tweaking. > Well, I wish do apologize to Måns if he thought I was ridiculing his > hardware. Just take out the last sentence with "modprobe" if it bothers > you. Well, my hardware is as good as any. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-11 10:15 ` Måns Rullgård @ 2003-12-11 11:05 ` Xavier Bestel 0 siblings, 0 replies; 103+ messages in thread From: Xavier Bestel @ 2003-12-11 11:05 UTC (permalink / raw) To: Måns Rullgård; +Cc: Linux Kernel Mailing List Le jeu 11/12/2003 à 11:15, Måns Rullgård a écrit : > I was objecting to the udev > way of thinking that all drivers are always loaded. If you want to > use udev and on-demand loading, you need to do some tweaking. Technically it's hotplug which assumes that all drivers are always to be loaded. But you are right. And even there, I'd say hotplug+udev has the advantage: being userland scripts, they can be tweaked to meet your needs (like on-demand loading only your floppy, in your case). Unlike devfs. Mechanism, not policy, etc. Xav ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:55 ` Xavier Bestel 2003-12-09 13:03 ` Maciej Zenczykowski @ 2003-12-10 0:38 ` Greg KH 1 sibling, 0 replies; 103+ messages in thread From: Greg KH @ 2003-12-10 0:38 UTC (permalink / raw) To: Xavier Bestel; +Cc: Witukind, recbo, Linux Kernel Mailing List On Tue, Dec 09, 2003 at 10:55:58AM +0100, Xavier Bestel wrote: > Le mar 09/12/2003 à 10:08, Greg KH a écrit : > > > That's something I don't understand: I thought that with a well > > > configured hotplug+udev system, you'll never have to worry about loading > > > drivers on device-node open() because all drivers should be auto-loaded > > > and all device-nodes should be auto-created. > > > > > > Am I wrong ? > > > > No, you are correct. That's why I'm not really worried about this, and > > I don't think anyone else should be either. > > So to attenuate people's worries it should be stated in some form: > > A: Such a functionality isn't needed on a properly configured > system. All devices present on the system should generate > hotplug events, loading the appropriate driver, and udev > should notice and create the appropriate device node. > In case of failure, please make a proper bug report. Thanks, I've now updated the udev FAQ with much this kind of wording to hoefully prevent this kind of thread happening again (hey, I can dream, can't I?) It can be found at: kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:00 ` Xavier Bestel 2003-12-09 9:08 ` Greg KH @ 2003-12-09 9:26 ` Måns Rullgård 2003-12-09 9:41 ` Miles Bader 1 sibling, 1 reply; 103+ messages in thread From: Måns Rullgård @ 2003-12-09 9:26 UTC (permalink / raw) To: linux-kernel Xavier Bestel <xavier.bestel@free.fr> writes: >> A: That is correct. If you really require this functionality, then >> use devfs. There is no way that udev can support this, and it >> never will. > > That's something I don't understand: I thought that with a well > configured hotplug+udev system, you'll never have to worry about loading > drivers on device-node open() because all drivers should be auto-loaded > and all device-nodes should be auto-created. > > Am I wrong ? Let me give an example. Hotplug will automatically load the ALSA drivers for my sound card, and /dev/snd/* are created (by devfs or udev, it doesn't matter for now). Suppose that, some time, I run a program that tries to use OSS for sound. Now, the ALSA OSS emulation is not loaded by hotplug, and I don't want it to. It's nice to have snd-pcm-oss automatically loaded when some legacy application tries to use /dev/dsp. -- Måns Rullgård mru@kth.se ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 9:26 ` Måns Rullgård @ 2003-12-09 9:41 ` Miles Bader 0 siblings, 0 replies; 103+ messages in thread From: Miles Bader @ 2003-12-09 9:41 UTC (permalink / raw) To: Måns Rullgård; +Cc: linux-kernel mru@kth.se (Måns Rullgård) writes: > Let me give an example. Hotplug will automatically load the ALSA > drivers for my sound card, and /dev/snd/* are created (by devfs or > udev, it doesn't matter for now). Suppose that, some time, I run a > program that tries to use OSS for sound. Now, the ALSA OSS emulation > is not loaded by hotplug, and I don't want it to. It's nice to have > snd-pcm-oss automatically loaded when some legacy application tries to > use /dev/dsp. For this sort of case it seems like it would be much cleaner to have some sort of proxy device that would load the module upon open -- so the also drivers would end up creating both alsa entries in /dev, and also proxy entries for the supported oss devices. That way, you could have the explicit device entry (which I think is all around saner), but not the overhead of rarely used modules. -Miles -- In New York, most people don't have cars, so if you want to kill a person, you have to take the subway to their house. And sometimes on the way, the train is delayed and you get impatient, so you have to kill someone on the subway. [George Carlin] ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 7:56 ` Greg KH 2003-12-09 9:00 ` Xavier Bestel @ 2003-12-10 8:13 ` Jakob Oestergaard 2003-12-10 8:24 ` Rob Landley 2 siblings, 0 replies; 103+ messages in thread From: Jakob Oestergaard @ 2003-12-10 8:13 UTC (permalink / raw) To: Greg KH; +Cc: Witukind, recbo, linux-kernel On Mon, Dec 08, 2003 at 11:56:20PM -0800, Greg KH wrote: > On Tue, Dec 09, 2003 at 06:17:28AM +0100, Witukind wrote: > > From the udev FAQ: > > > > Q: But udev will not automatically load a driver if a /dev node is opened > > when it is not present like devfs will do. > > A: If you really require this functionality, then use devfs. It is still > > present in the kernel. > > > > Will it have this 'equivalent functionality' some day? > > Heh, no. I really don't believe all of the people who keep asking me > this. I think I need to reword this answer to something like: > A: That is correct. If you really require this functionality, then > use devfs. There is no way that udev can support this, and it > never will. > > That better? :) No Greg. People keep asking, because you continue to give an answer that is 'correct' but does not answer the question people 'meant' to ask. Andreas Jellinghaus <aj@dungeon.inka.de> gave an excellent answer - which I shall blatantly quote: ------------------------- Q: devfs did load drivers when someone tried to open() a non existing device. will sysfs/hotplug/udev do this? A: there is no need to. hotplug/sysfs/udev will create devices for all hardware supported by the kernel and the available modules. it will do that during boot up, and whenever new hardware is added. so you can expect all devices be already present, no need for a devfs like mechanism. ------------------------- And there you have it :) / jakob ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: udev sysfs docs Re: State of devfs in 2.6? 2003-12-09 7:56 ` Greg KH 2003-12-09 9:00 ` Xavier Bestel 2003-12-10 8:13 ` Jakob Oestergaard @ 2003-12-10 8:24 ` Rob Landley 2 siblings, 0 replies; 103+ messages in thread From: Rob Landley @ 2003-12-10 8:24 UTC (permalink / raw) To: Greg KH, Witukind; +Cc: recbo, linux-kernel On Tuesday 09 December 2003 01:56, Greg KH wrote: > On Tue, Dec 09, 2003 at 06:17:28AM +0100, Witukind wrote: > > From the udev FAQ: > > > > Q: But udev will not automatically load a driver if a /dev node is opened > > when it is not present like devfs will do. > > A: If you really require this functionality, then use devfs. It is still > > present in the kernel. > > > > Will it have this 'equivalent functionality' some day? > > Heh, no. I really don't believe all of the people who keep asking me > this. I think I need to reword this answer to something like: > A: That is correct. If you really require this functionality, then > use devfs. There is no way that udev can support this, and it > never will. > > That better? :) > > thanks, > > greg k-h I think another way of saying it is that we now have a hotplug infrastructure to load the driver on an insert event, so if you want to load the driver for something that A) isn't detected on startup, B) isn't detected on a hotplug event when it's inserted after startup, the way to do it is to call modprobe, not to mknod a random device node and then try to open it and hope some magic side effect of open loads the correct module with the right parameters to make things work. The driver is now loaded while the device is attached to the system, not just while the device is in use. (Less races that way, you get to save state between invocations, etc.) The lifetime rules changed. The old way of doing it assumes you have a device node for a device that has no driver loaded, which was the default under the old static /dev but not the case in a fully hotplug system. You have /dev nodes for devices that are in the system (with drivers loaded), and you don't for ones that aren't. Rob (I could be completely wrong about all this, of course...) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 15:42 ` William Lee Irwin III 2003-12-08 15:59 ` Andrew Walrond 2003-12-08 19:09 ` udev sysfs docs " Bob @ 2003-12-08 23:04 ` Andreas Jellinghaus 2003-12-08 23:34 ` Greg KH 2 siblings, 1 reply; 103+ messages in thread From: Andreas Jellinghaus @ 2003-12-08 23:04 UTC (permalink / raw) To: linux-kernel On Mon, 08 Dec 2003 15:50:45 +0000, William Lee Irwin III wrote: > I would say it's deprecated at the very least. sysfs and udev are > supposed to provide equivalent functionality, albeit by a somewhat > different mechanism. huh? aj@simulacron:/dev$ find -type c -mount |grep -v pty |wc -l 164 aj@simulacron:/dev$ find -type b |wc -l 157 aj@simulacron:/dev$ find /sys/ -name dev |wc -l 250 After ignoring .devfsd we are left with 70 devices missing: - 15 floppy devices - 5 input/ devices - full, kmem, kmsg, mem, null, port, random, urandom, zero - printers/0 - 5 misc/ devices - 12 snd/ devices - 5 sound/ devices - 18 vcc/ devices I wouldn't call udev deprecated, unless a newer kernel has the essential devices, too. And is there a udev version that can do devfs names? last time I checked only lanana names were supported. Some distributions were quite happy to move from /dev and lanana to devfs with better names. I doubt everyone will rush to udev with lanana names, and re-introducing makedev for devices not represented in sysfs doesn't sound very nice either. So 2.8.* might be a nice time frame for dropping devfs, or at least give sysfs and udev a few months to catch up on the issues mentioned. Andreas ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 23:04 ` Andreas Jellinghaus @ 2003-12-08 23:34 ` Greg KH 2003-12-09 0:31 ` Sven-Haegar Koch ` (5 more replies) 0 siblings, 6 replies; 103+ messages in thread From: Greg KH @ 2003-12-08 23:34 UTC (permalink / raw) To: Andreas Jellinghaus; +Cc: linux-kernel On Tue, Dec 09, 2003 at 12:04:08AM +0100, Andreas Jellinghaus wrote: > On Mon, 08 Dec 2003 15:50:45 +0000, William Lee Irwin III wrote: > > I would say it's deprecated at the very least. sysfs and udev are > > supposed to provide equivalent functionality, albeit by a somewhat > > different mechanism. > > huh? > > aj@simulacron:/dev$ find -type c -mount |grep -v pty |wc -l > 164 > aj@simulacron:/dev$ find -type b |wc -l > 157 > aj@simulacron:/dev$ find /sys/ -name dev |wc -l > 250 > > After ignoring .devfsd we are left with 70 devices missing: > - 15 floppy devices You have 15 floppy devices connected to your box? All floppy devices should show up in /sys/block. > - 5 input/ devices Patch for sysfs support for this has been posted by Hanna Linder. It still needs work before being added to the kernel tree. > - full, kmem, kmsg, mem, null, port, random, urandom, zero Patch for this has been posted by me to lkml in the past. It will probably go into 2.6.1 > - printers/0 Hanna Linder is working on a patch for these devices. > - 5 misc/ devices Patch for this has been posted by me to lkml in the past. It will probably go into 2.6.1. > - 12 snd/ devices > - 5 sound/ devices I have a patch here from Leann Ogasawara that adds sysfs support for these devices. I've been lacking time to test it better, but again, it will probably make it into 2.6.1. > - 18 vcc/ devices Hm, good catch. I wonder why these aren't getting picked up in /sys/class/tty as they are tty devices. I thought they used to be there... > I wouldn't call udev deprecated, unless a newer kernel has the > essential devices, too. You mean s/udev/devfs/ right? :) > And is there a udev version that can > do devfs names? last time I checked only lanana names were supported. There is a udev config file that was just posted to linux-hotplug-devel that supports a lot of devfs names. If there are any missing that you use, please post a config file for them. Remember, I don't use devfs, so I really don't care about a udev mapping for it :) > Some distributions were quite happy to move from /dev and lanana to > devfs with better names. Hm, 2? And one of them (Mandrake) got smart and went back... > I doubt everyone will rush to udev with lanana names, Why not? It's the standard afterall. Remember, the devfs users are in the tiny minority here. > and > re-introducing makedev for devices not represented > in sysfs doesn't sound very nice either. So 2.8.* might be a nice time > frame for dropping devfs, or at least give sysfs and udev a few months > to catch up on the issues mentioned. Regardless of the state of udev, devfs has insolvable problems and you should not use it. End of story. thanks, greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 23:34 ` Greg KH @ 2003-12-09 0:31 ` Sven-Haegar Koch 2003-12-09 0:42 ` Greg KH 2003-12-09 0:51 ` [PATCH] sysfs support for vcs devices (was Re: State of devfs in 2.6?) Greg KH ` (4 subsequent siblings) 5 siblings, 1 reply; 103+ messages in thread From: Sven-Haegar Koch @ 2003-12-09 0:31 UTC (permalink / raw) To: Greg KH; +Cc: Andreas Jellinghaus, linux-kernel On Mon, 8 Dec 2003, Greg KH wrote: > > After ignoring .devfsd we are left with 70 devices missing: > > - 15 floppy devices > > You have 15 floppy devices connected to your box? All floppy devices > should show up in /sys/block. perhaps he means fd0u1440, fd0u1600 and friends ls /dev/fd0u*|wc -l -> 15 c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 0:31 ` Sven-Haegar Koch @ 2003-12-09 0:42 ` Greg KH 0 siblings, 0 replies; 103+ messages in thread From: Greg KH @ 2003-12-09 0:42 UTC (permalink / raw) To: Sven-Haegar Koch; +Cc: Andreas Jellinghaus, linux-kernel On Tue, Dec 09, 2003 at 01:31:00AM +0100, Sven-Haegar Koch wrote: > On Mon, 8 Dec 2003, Greg KH wrote: > > > > After ignoring .devfsd we are left with 70 devices missing: > > > - 15 floppy devices > > > > You have 15 floppy devices connected to your box? All floppy devices > > should show up in /sys/block. > > perhaps he means fd0u1440, fd0u1600 and friends > > ls /dev/fd0u*|wc -l -> 15 Yeah, but are those devices actually connected all at once? Yeah, I know the way of talking to the same device in different manners... Hm, udev can now do symlinks, does it also need to handle multiple minors for floppy devices? I'll have to look into how the kernel handles the different block minors for floppy devices. thanks, greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* [PATCH] sysfs support for vcs devices (was Re: State of devfs in 2.6?) 2003-12-08 23:34 ` Greg KH 2003-12-09 0:31 ` Sven-Haegar Koch @ 2003-12-09 0:51 ` Greg KH 2003-12-09 5:26 ` State of devfs in 2.6? Rob Landley ` (3 subsequent siblings) 5 siblings, 0 replies; 103+ messages in thread From: Greg KH @ 2003-12-09 0:51 UTC (permalink / raw) To: Andreas Jellinghaus; +Cc: linux-kernel On Mon, Dec 08, 2003 at 03:34:28PM -0800, Greg KH wrote: > On Tue, Dec 09, 2003 at 12:04:08AM +0100, Andreas Jellinghaus wrote: > > - 18 vcc/ devices > > Hm, good catch. I wonder why these aren't getting picked up in > /sys/class/tty as they are tty devices. I thought they used to be > there... Ah, they really aren't tty devices, they are char devices. That's why they never have showed up. Anyway, here's a patch against 2.6.0-test11 that adds sysfs support for all of the vcs devices. Now udev has support for them :) thanks for pointing these out, greg k-h # add /sys/class/vc support for the vcs devices. diff -Nru a/drivers/char/vc_screen.c b/drivers/char/vc_screen.c --- a/drivers/char/vc_screen.c Mon Dec 8 16:49:54 2003 +++ b/drivers/char/vc_screen.c Mon Dec 8 16:49:54 2003 @@ -36,6 +36,7 @@ #include <linux/kbd_kern.h> #include <linux/console.h> #include <linux/smp_lock.h> +#include <linux/device.h> #include <asm/uaccess.h> #include <asm/byteorder.h> #include <asm/unaligned.h> @@ -469,6 +470,85 @@ .open = vcs_open, }; +/* vc class implementation */ + +struct vc_dev { + struct list_head node; + dev_t dev; + struct class_device class_dev; +}; +#define to_vc_dev(d) container_of(d, struct vc_dev, class_dev) + +static LIST_HEAD(vc_dev_list); +static spinlock_t vc_dev_list_lock = SPIN_LOCK_UNLOCKED; + +static void release_vc_dev(struct class_device *class_dev) +{ + struct vc_dev *vc_dev = to_vc_dev(class_dev); + kfree(vc_dev); +} + +static struct class vc_class = { + .name = "vc", + .release = &release_vc_dev, +}; + +static ssize_t show_dev(struct class_device *class_dev, char *buf) +{ + struct vc_dev *vc_dev = to_vc_dev(class_dev); + return print_dev_t(buf, vc_dev->dev); +} +static CLASS_DEVICE_ATTR(dev, S_IRUGO, show_dev, NULL); + +static int vc_add_class_device(dev_t dev, char *name, int minor) +{ + struct vc_dev *vc_dev = NULL; + int retval; + + vc_dev = kmalloc(sizeof(*vc_dev), GFP_KERNEL); + if (!vc_dev) + return -ENOMEM; + memset(vc_dev, 0x00, sizeof(*vc_dev)); + + vc_dev->dev = dev; + vc_dev->class_dev.class = &vc_class; + snprintf(vc_dev->class_dev.class_id, BUS_ID_SIZE, name, minor); + retval = class_device_register(&vc_dev->class_dev); + if (retval) + goto error; + class_device_create_file(&vc_dev->class_dev, &class_device_attr_dev); + spin_lock(&vc_dev_list_lock); + list_add(&vc_dev->node, &vc_dev_list); + spin_unlock(&vc_dev_list_lock); + return 0; +error: + kfree(vc_dev); + return retval; +} + +static void vc_remove_class_device(int minor) +{ + struct vc_dev *vc_dev = NULL; + struct list_head *tmp; + int found = 0; + + spin_lock(&vc_dev_list_lock); + list_for_each(tmp, &vc_dev_list) { + vc_dev = list_entry(tmp, struct vc_dev, node); + if (MINOR(vc_dev->dev) == minor) { + found = 1; + break; + } + } + if (found) { + list_del(&vc_dev->node); + spin_unlock(&vc_dev_list_lock); + class_device_unregister(&vc_dev->class_dev); + } else { + spin_unlock(&vc_dev_list_lock); + } +} + void vcs_make_devfs(struct tty_struct *tty) { devfs_mk_cdev(MKDEV(VCS_MAJOR, tty->index + 1), @@ -477,19 +557,26 @@ devfs_mk_cdev(MKDEV(VCS_MAJOR, tty->index + 129), S_IFCHR|S_IRUSR|S_IWUSR, "vcc/a%u", tty->index + 1); + vc_add_class_device(MKDEV(VCS_MAJOR, tty->index + 1), "vcs%u", tty->index + 1); + vc_add_class_device(MKDEV(VCS_MAJOR, tty->index + 129), "vcsa%u", tty->index + 1); } void vcs_remove_devfs(struct tty_struct *tty) { devfs_remove("vcc/%u", tty->index + 1); devfs_remove("vcc/a%u", tty->index + 1); + vc_remove_class_device(tty->index + 1); + vc_remove_class_device(tty->index + 129); } int __init vcs_init(void) { if (register_chrdev(VCS_MAJOR, "vcs", &vcs_fops)) panic("unable to get major %d for vcs device", VCS_MAJOR); + class_register(&vc_class); devfs_mk_cdev(MKDEV(VCS_MAJOR, 0), S_IFCHR|S_IRUSR|S_IWUSR, "vcc/0"); devfs_mk_cdev(MKDEV(VCS_MAJOR, 128), S_IFCHR|S_IRUSR|S_IWUSR, "vcc/a0"); + vc_add_class_device(MKDEV(VCS_MAJOR, 0), "vcs", 0); + vc_add_class_device(MKDEV(VCS_MAJOR, 128), "vcsa", 128); return 0; } ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 23:34 ` Greg KH 2003-12-09 0:31 ` Sven-Haegar Koch 2003-12-09 0:51 ` [PATCH] sysfs support for vcs devices (was Re: State of devfs in 2.6?) Greg KH @ 2003-12-09 5:26 ` Rob Landley 2003-12-09 18:19 ` Greg KH 2003-12-09 18:20 ` Greg KH 2003-12-09 7:02 ` Andreas Jellinghaus ` (2 subsequent siblings) 5 siblings, 2 replies; 103+ messages in thread From: Rob Landley @ 2003-12-09 5:26 UTC (permalink / raw) To: Greg KH, Andreas Jellinghaus; +Cc: linux-kernel On Monday 08 December 2003 17:34, Greg KH wrote: > > - 5 input/ devices > > Patch for sysfs support for this has been posted by Hanna Linder. It > still needs work before being added to the kernel tree. > > > - full, kmem, kmsg, mem, null, port, random, urandom, zero > > Patch for this has been posted by me to lkml in the past. It will > probably go into 2.6.1 > > > - printers/0 > > Hanna Linder is working on a patch for these devices. > > > - 5 misc/ devices > > Patch for this has been posted by me to lkml in the past. It will > probably go into 2.6.1. > > > - 12 snd/ devices > > - 5 sound/ devices > > I have a patch here from Leann Ogasawara that adds sysfs support for > these devices. I've been lacking time to test it better, but again, it > will probably make it into 2.6.1. Is there a big rollup patch against that adds all the sys/*/dev entries for people who want to try udev? Rob ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 5:26 ` State of devfs in 2.6? Rob Landley @ 2003-12-09 18:19 ` Greg KH 2003-12-09 18:20 ` Greg KH 1 sibling, 0 replies; 103+ messages in thread From: Greg KH @ 2003-12-09 18:19 UTC (permalink / raw) To: Rob Landley; +Cc: Andreas Jellinghaus, linux-kernel On Mon, Dec 08, 2003 at 11:26:17PM -0600, Rob Landley wrote: > > Is there a big rollup patch against that adds all the sys/*/dev entries for > people who want to try udev? After I get finished catching up on USB patches that people sent me for the last month, I'll generate this and post it to lkml. thanks, greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 5:26 ` State of devfs in 2.6? Rob Landley 2003-12-09 18:19 ` Greg KH @ 2003-12-09 18:20 ` Greg KH 1 sibling, 0 replies; 103+ messages in thread From: Greg KH @ 2003-12-09 18:20 UTC (permalink / raw) To: Rob Landley; +Cc: Andreas Jellinghaus, linux-kernel On Mon, Dec 08, 2003 at 11:26:17PM -0600, Rob Landley wrote: > Is there a big rollup patch against that adds all the sys/*/dev entries for > people who want to try udev? Oh, and you can try udev today with no kernel patches needed. All block devices and tty devices and i2c dev devices and usb major devices and v4l devices work just fine with udev on 2.6.0-test11. thanks, greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 23:34 ` Greg KH ` (2 preceding siblings ...) 2003-12-09 5:26 ` State of devfs in 2.6? Rob Landley @ 2003-12-09 7:02 ` Andreas Jellinghaus 2003-12-09 7:13 ` Murray J. Root 2003-12-09 8:32 ` State of devfs in 2.6? Greg KH 2003-12-09 7:33 ` Vojtech Pavlik 2003-12-09 9:48 ` Andreas Jellinghaus 5 siblings, 2 replies; 103+ messages in thread From: Andreas Jellinghaus @ 2003-12-09 7:02 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel On Tue, 2003-12-09 at 00:34, Greg KH wrote: > You have 15 floppy devices connected to your box? All floppy devices > should show up in /sys/block. No, 16 devices are normal, sysfs has only one: aj@simulacron:~/torrent/j-tv/download$ ls /dev/floppy/ 0 0u1120 0u1600 0u1722 0u1760 0u1920 0u720 0u820 0u1040 0u1440 0u1680 0u1743 0u1840 0u360 0u800 0u830 aj@simulacron:~/torrent/j-tv/download$ find /sys/block/fd* -name dev /sys/block/fd0/dev Are those floppy devices obsolete? fdformat was the only app to use them anyway, I guess. (Not that I use my floppy, I simply noticed the change.) > > I wouldn't call udev deprecated, unless a newer kernel has the > > essential devices, too. > > You mean s/udev/devfs/ right? :) oops, sorry. > > and > > re-introducing makedev for devices not represented > > in sysfs doesn't sound very nice either. So 2.8.* might be a nice time > > frame for dropping devfs, or at least give sysfs and udev a few months > > to catch up on the issues mentioned. > > Regardless of the state of udev, devfs has insolvable problems and you > should not use it. End of story. how many bug reports did you see in the last three months of people having problems with devfs? I don't doubt the problems in theory, but but I simply haven't seen them happening. Most users seem quite happy. Andreas ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 7:02 ` Andreas Jellinghaus @ 2003-12-09 7:13 ` Murray J. Root 2003-12-09 8:21 ` Holger Schurig 2003-12-09 8:32 ` State of devfs in 2.6? Greg KH 1 sibling, 1 reply; 103+ messages in thread From: Murray J. Root @ 2003-12-09 7:13 UTC (permalink / raw) To: linux-kernel On Tue, Dec 09, 2003 at 08:02:19AM +0100, Andreas Jellinghaus wrote: > On Tue, 2003-12-09 at 00:34, Greg KH wrote: > > You have 15 floppy devices connected to your box? All floppy devices > > should show up in /sys/block. > > No, 16 devices are normal, sysfs has only one: > aj@simulacron:~/torrent/j-tv/download$ ls /dev/floppy/ > 0 0u1120 0u1600 0u1722 0u1760 0u1920 0u720 0u820 > 0u1040 0u1440 0u1680 0u1743 0u1840 0u360 0u800 0u830 > aj@simulacron:~/torrent/j-tv/download$ find /sys/block/fd* -name dev > /sys/block/fd0/dev > > Are those floppy devices obsolete? fdformat was the only app to use > them anyway, I guess. (Not that I use my floppy, I simply noticed > the change.) > > > > I wouldn't call udev deprecated, unless a newer kernel has the > > > essential devices, too. > > > > You mean s/udev/devfs/ right? :) > > oops, sorry. > > > > and > > > re-introducing makedev for devices not represented > > > in sysfs doesn't sound very nice either. So 2.8.* might be a nice time > > > frame for dropping devfs, or at least give sysfs and udev a few months > > > to catch up on the issues mentioned. > > > > Regardless of the state of udev, devfs has insolvable problems and you > > should not use it. End of story. > > how many bug reports did you see in the last three months of people > having problems with devfs? I don't doubt the problems in theory, but > but I simply haven't seen them happening. Most users seem quite happy. > Actually, I think most users who have problems just disable devfs. Most of the people I know have done that. No point in making bug reports about something that is unmaintained and deprecated. -- Murray J. Root ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 7:13 ` Murray J. Root @ 2003-12-09 8:21 ` Holger Schurig 2003-12-09 8:52 ` Miles Bader 2003-12-09 17:10 ` Mark Mielke 0 siblings, 2 replies; 103+ messages in thread From: Holger Schurig @ 2003-12-09 8:21 UTC (permalink / raw) To: linux-kernel >> how many bug reports did you see in the last three months of people >> having problems with devfs? I don't doubt the problems in theory, but >> but I simply haven't seen them happening. Most users seem quite happy. >> > > Actually, I think most users who have problems just disable devfs. Most of > the people I know have done that. No point in making bug reports about > something that is unmaintained and deprecated. No, not really. Devfs for embedded devices is just great. It's all in the kernel, no external process to run (I use my embedded stuff without devfsd). I'm using it for about one year with various kernels. For me, I see several benefits: * space. devfs doesn't eat space like the MAKEDEV approach. * simplicity: I run my system without devfsd and without an initial ramdisk. All needed modules are simply compiled into the kernel. * No need for overcomplification, e.g a process that has to be started before userspace touches /dev, a specially compiled uclibc-based proggy in an initrd So, when /dev is accessed by userspace, all is there and well. -- Try Linux 2.6 from BitKeeper for PXA2x0 CPUs at http://www.mn-logistik.de/unsupported/linux-2.6/ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 8:21 ` Holger Schurig @ 2003-12-09 8:52 ` Miles Bader 2003-12-09 10:08 ` Holger Schurig 2003-12-09 17:10 ` Mark Mielke 1 sibling, 1 reply; 103+ messages in thread From: Miles Bader @ 2003-12-09 8:52 UTC (permalink / raw) To: Holger Schurig; +Cc: linux-kernel Holger Schurig <h.schurig@mn-logistik.de> writes: > Devfs for embedded devices is just great. > > * space. devfs doesn't eat space like the MAKEDEV approach. Um, devfs does actually use a non-zero amount of code... For a typical embedded device with about 5 entries in /dev I wouldn't be surprised if devfs used a lot _more_ space... -miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 8:52 ` Miles Bader @ 2003-12-09 10:08 ` Holger Schurig 0 siblings, 0 replies; 103+ messages in thread From: Holger Schurig @ 2003-12-09 10:08 UTC (permalink / raw) To: linux-kernel >> * space. devfs doesn't eat space like the MAKEDEV approach. > > Um, devfs does actually use a non-zero amount of code... Yeh, it uses code. But if you look into a MAKEDEV bases file system, you see hundreds of device files. Which uses inode and directory space on the medium, may it be e2fs or jffs2. I did not measure if the code for devfs is smaller as the code+config files for udev. But I didn't make a statement about this. > For a typical embedded device with about 5 entries in /dev I wouldn't > be surprised if devfs used a lot _more_ space... # find /dev | wc -l 326 "Embedded" is not automatically a washing maschine with only 5 entries, it can be a full blown Linux computer with 400 MHz, Framebuffer, USB Host, USB Client, 7 serial ports for GSM, Barcode Scanner, Whatever, and so on. Like our device. However, even on such hardware-rich devices you usually have a constraint on Flash Memory size. So having things small & simple is nice. That makes room for the user applications & data. -- Try Linux 2.6 from BitKeeper for PXA2x0 CPUs at http://www.mn-logistik.de/unsupported/linux-2.6/ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 8:21 ` Holger Schurig 2003-12-09 8:52 ` Miles Bader @ 2003-12-09 17:10 ` Mark Mielke 2003-12-10 5:42 ` Greg KH 1 sibling, 1 reply; 103+ messages in thread From: Mark Mielke @ 2003-12-09 17:10 UTC (permalink / raw) To: Holger Schurig; +Cc: linux-kernel On Tue, Dec 09, 2003 at 09:21:56AM +0100, Holger Schurig wrote: > Devfs for embedded devices is just great. It's all in the kernel, no > external process to run (I use my embedded stuff without devfsd). I'm using > it for about one year with various kernels. I don't see why 'all in the kernel' is the best approach, embedded or otherwise. I believe udev is being written to execute with a minimal runtime environment. No glibc, or other such beasts. > * space. devfs doesn't eat space like the MAKEDEV approach. Can you prove this? tmpfs doesn't seem to take up much space, and given that only devices that exist will require data structures in both cases, it seems to me that the issue is a little irrelevant in either case. > * simplicity: I run my system without devfsd and without an initial ramdisk. > All needed modules are simply compiled into the kernel. Isn't this an argument for udev? > * No need for overcomplification, e.g a process that has to be started > before userspace touches /dev, a specially compiled uclibc-based proggy in > an initrd Many of us believe that devfs is 'over-complification'. > So, when /dev is accessed by userspace, all is there and well. True in either case... mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 17:10 ` Mark Mielke @ 2003-12-10 5:42 ` Greg KH 2003-12-10 23:29 ` jw schultz 2003-12-11 20:32 ` [2.4.23] cursor dissapears in framebuffer console after switching back from X Witukind 0 siblings, 2 replies; 103+ messages in thread From: Greg KH @ 2003-12-10 5:42 UTC (permalink / raw) To: Mark Mielke; +Cc: Holger Schurig, linux-kernel On Tue, Dec 09, 2003 at 12:10:47PM -0500, Mark Mielke wrote: > On Tue, Dec 09, 2003 at 09:21:56AM +0100, Holger Schurig wrote: > > Devfs for embedded devices is just great. It's all in the kernel, no > > external process to run (I use my embedded stuff without devfsd). I'm using > > it for about one year with various kernels. > > I don't see why 'all in the kernel' is the best approach, embedded or > otherwise. I believe udev is being written to execute with a minimal > runtime environment. No glibc, or other such beasts. Exactly. The current bk tree version of udev (which has more features than the 008 release) is weighing in at 49Kb, linked statically, no external dependancies. greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-10 5:42 ` Greg KH @ 2003-12-10 23:29 ` jw schultz 2003-12-11 20:32 ` [2.4.23] cursor dissapears in framebuffer console after switching back from X Witukind 1 sibling, 0 replies; 103+ messages in thread From: jw schultz @ 2003-12-10 23:29 UTC (permalink / raw) To: linux-kernel On Tue, Dec 09, 2003 at 09:42:54PM -0800, Greg KH wrote: > On Tue, Dec 09, 2003 at 12:10:47PM -0500, Mark Mielke wrote: > > On Tue, Dec 09, 2003 at 09:21:56AM +0100, Holger Schurig wrote: > > > Devfs for embedded devices is just great. It's all in the kernel, no > > > external process to run (I use my embedded stuff without devfsd). I'm using > > > it for about one year with various kernels. > > > > I don't see why 'all in the kernel' is the best approach, embedded or > > otherwise. I believe udev is being written to execute with a minimal > > runtime environment. No glibc, or other such beasts. > > Exactly. The current bk tree version of udev (which has more features > than the 008 release) is weighing in at 49Kb, linked statically, no > external dependancies. And if we are talking about the smaller embedded systems it would be good to remember that their /dev doesn't really change much so devfs and udev could be left out entirely by having a small staticly populated /dev in the initramfs/initrd image, or whatever is used for /. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt ^ permalink raw reply [flat|nested] 103+ messages in thread
* [2.4.23] cursor dissapears in framebuffer console after switching back from X 2003-12-10 5:42 ` Greg KH 2003-12-10 23:29 ` jw schultz @ 2003-12-11 20:32 ` Witukind 2003-12-11 23:59 ` Gene Heskett 1 sibling, 1 reply; 103+ messages in thread From: Witukind @ 2003-12-11 20:32 UTC (permalink / raw) To: linux-kernel [-- Attachment #1: Type: text/plain, Size: 365 bytes --] This is 100% reproduceable on my machine. When I boot Linux the cursor can be seen. then I start XFree86 and when I switch back to the framebuffer console with ALT-CTRL-F(x) it is not there anymore. I am using tdfx.o with a Voodoo 3 2000 PCI, XFree86 4.3.0 (Slackware 9.1). If more information is needed I'll be glad to provide it. -- Jabber: heimdal@jabber.org [-- Attachment #2: .config --] [-- Type: application/octet-stream, Size: 22809 bytes --] # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set CONFIG_MK6=y # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_HAS_TSC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_MCE=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_HIGHMEM is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set # CONFIG_X86_TSC_DISABLE is not set CONFIG_X86_TSC=y # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_ISA=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_PM is not set # CONFIG_APM is not set # # ACPI Support # # CONFIG_ACPI is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_CISS_MONITOR_THREAD is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_BLK_STATS is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # # Appletalk devices # # CONFIG_DEV_APPLETALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_IDEDISK_STROKE is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_GENERIC=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_BLK_DEV_ADMA100 is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_AMD74XX_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_RZ1000 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_ATARAID is not set # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set # CONFIG_BLK_DEV_ATARAID_SII is not set # # SCSI support # CONFIG_SCSI=m CONFIG_BLK_DEV_SD=m CONFIG_SD_EXTRA_DEVS=2 # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=m CONFIG_SCSI_DEBUG_QUEUES=y # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_MEGARAID2 is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_NCR53C8XX is not set # CONFIG_SCSI_SYM53C8XX is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_CS89x0 is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_EEPRO100_PIO is not set # CONFIG_E100 is not set # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=m # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_SUNDANCE_MMIO is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PLIP=m # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # CONFIG_INPUT=m CONFIG_INPUT_KEYBDEV=m CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=m # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=512 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # CONFIG_INPUT_NS558 is not set # CONFIG_INPUT_LIGHTNING is not set # CONFIG_INPUT_PCIGAME is not set # CONFIG_INPUT_CS461X is not set # CONFIG_INPUT_EMU10K1 is not set # CONFIG_INPUT_SERIO is not set # CONFIG_INPUT_SERPORT is not set # CONFIG_INPUT_ANALOG is not set # CONFIG_INPUT_A3D is not set # CONFIG_INPUT_ADI is not set # CONFIG_INPUT_COBRA is not set # CONFIG_INPUT_GF2K is not set # CONFIG_INPUT_GRIP is not set # CONFIG_INPUT_INTERACT is not set # CONFIG_INPUT_TMDC is not set # CONFIG_INPUT_SIDEWINDER is not set # CONFIG_INPUT_IFORCE_USB is not set # CONFIG_INPUT_IFORCE_232 is not set # CONFIG_INPUT_WARRIOR is not set # CONFIG_INPUT_MAGELLAN is not set # CONFIG_INPUT_SPACEORB is not set # CONFIG_INPUT_SPACEBALL is not set # CONFIG_INPUT_STINGER is not set # CONFIG_INPUT_DB9 is not set # CONFIG_INPUT_GAMECON is not set # CONFIG_INPUT_TURBOGRAFX is not set # CONFIG_QIC02_TAPE is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_IPMI_PANIC_EVENT is not set # CONFIG_IPMI_DEVICE_INTERFACE is not set # CONFIG_IPMI_KCS is not set # CONFIG_IPMI_WATCHDOG is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_SCx200_GPIO is not set # CONFIG_AMD_RNG is not set # CONFIG_INTEL_RNG is not set # CONFIG_HW_RANDOM is not set # CONFIG_AMD_PM768 is not set CONFIG_NVRAM=m CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # # Direct Rendering Manager (XFree86 DRI support) # CONFIG_DRM=y # CONFIG_DRM_OLD is not set CONFIG_DRM_NEW=y CONFIG_DRM_TDFX=m # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set # CONFIG_DRM_I810_XFREE_41 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_MWAVE is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_QFMT_V2 is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BEFS_DEBUG is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set # CONFIG_TMPFS is not set CONFIG_RAMFS=y CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_ZISOFS is not set # CONFIG_JFS_FS is not set # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set CONFIG_NTFS_FS=m # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set # CONFIG_EXT2_FS is not set # CONFIG_SYSV_FS is not set CONFIG_UDF_FS=m # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set # CONFIG_NFS_FS is not set # CONFIG_NFS_V3 is not set # CONFIG_NFS_DIRECTIO is not set # CONFIG_ROOT_NFS is not set # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set # CONFIG_NFSD_TCP is not set # CONFIG_SUNRPC is not set # CONFIG_LOCKD is not set CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_ZISOFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="cp437" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y # CONFIG_FB_RIVA is not set # CONFIG_FB_CLGEN is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_VESA is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_HGA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_MATROX is not set # CONFIG_FB_ATY is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set CONFIG_FB_3DFX=y # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set CONFIG_FBCON_ADVANCED=y # CONFIG_FBCON_MFB is not set # CONFIG_FBCON_CFB2 is not set # CONFIG_FBCON_CFB4 is not set CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y # CONFIG_FBCON_CFB24 is not set # CONFIG_FBCON_CFB32 is not set # CONFIG_FBCON_AFB is not set # CONFIG_FBCON_ILBM is not set # CONFIG_FBCON_IPLAN2P2 is not set # CONFIG_FBCON_IPLAN2P4 is not set # CONFIG_FBCON_IPLAN2P8 is not set # CONFIG_FBCON_MAC is not set # CONFIG_FBCON_VGA_PLANES is not set # CONFIG_FBCON_VGA is not set # CONFIG_FBCON_HGA is not set # CONFIG_FBCON_FONTWIDTH8_ONLY is not set CONFIG_FBCON_FONTS=y # CONFIG_FONT_8x8 is not set CONFIG_FONT_8x16=y CONFIG_FONT_SUN8x16=y # CONFIG_FONT_SUN12x22 is not set # CONFIG_FONT_6x11 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # # Sound # CONFIG_SOUND=m # CONFIG_SOUND_ALI5455 is not set # CONFIG_SOUND_BT878 is not set # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_MIDI_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_FORTE is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_MIDI_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # CONFIG_SOUND_TVMIXER is not set # CONFIG_SOUND_AD1980 is not set # CONFIG_SOUND_WM97XX is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_EHCI_HCD is not set CONFIG_USB_UHCI=m # CONFIG_USB_UHCI_ALT is not set # CONFIG_USB_OHCI is not set # CONFIG_USB_SL811HS_ALT is not set # CONFIG_USB_SL811HS is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_MIDI is not set CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set CONFIG_USB_STORAGE_DPCM=y # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_USB_HIDDEV is not set # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_CATC is not set # CONFIG_USB_AX8817X is not set # CONFIG_USB_CDCETHER is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_BRLVGER is not set # CONFIG_USB_LCD is not set # # Support for USB gadgets # # CONFIG_USB_GADGET is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_FRAME_POINTER is not set CONFIG_LOG_BUF_SHIFT=0 # # Cryptographic options # # CONFIG_CRYPTO is not set # # Library routines # # CONFIG_CRC32 is not set CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m # CONFIG_FW_LOADER is not set ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [2.4.23] cursor dissapears in framebuffer console after switching back from X 2003-12-11 20:32 ` [2.4.23] cursor dissapears in framebuffer console after switching back from X Witukind @ 2003-12-11 23:59 ` Gene Heskett 2003-12-12 6:24 ` Witukind 0 siblings, 1 reply; 103+ messages in thread From: Gene Heskett @ 2003-12-11 23:59 UTC (permalink / raw) To: Witukind, linux-kernel On Thursday 11 December 2003 15:32, Witukind wrote: >This is 100% reproduceable on my machine. When I boot Linux the > cursor can be seen. then I start XFree86 and when I switch back to > the framebuffer console with ALT-CTRL-F(x) it is not there anymore. > I am using tdfx.o with a Voodoo 3 2000 PCI, XFree86 4.3.0 > (Slackware 9.1). If more information is needed I'll be glad to > provide it. This was asked by me a week or 2 back,and the answer is that in your .config that built your kernel, you probably have both a framebuffer for your card enabled, and a generic vesa framebuffer. Turn off the generic framebuffer and make/reinstall your kernel. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [2.4.23] cursor dissapears in framebuffer console after switching back from X 2003-12-11 23:59 ` Gene Heskett @ 2003-12-12 6:24 ` Witukind 0 siblings, 0 replies; 103+ messages in thread From: Witukind @ 2003-12-12 6:24 UTC (permalink / raw) To: gene.heskett; +Cc: linux-kernel On Thu, 11 Dec 2003 18:59:55 -0500 Gene Heskett <gene.heskett@verizon.net> wrote: > On Thursday 11 December 2003 15:32, Witukind wrote: > >This is 100% reproduceable on my machine. When I boot Linux the > > cursor can be seen. then I start XFree86 and when I switch back to > > the framebuffer console with ALT-CTRL-F(x) it is not there anymore. > > I am using tdfx.o with a Voodoo 3 2000 PCI, XFree86 4.3.0 > > (Slackware 9.1). If more information is needed I'll be glad to > > provide it. > > This was asked by me a week or 2 back,and the answer is that in your > .config that built your kernel, you probably have both a framebuffer > for your card enabled, and a generic vesa framebuffer. Turn off the > generic framebuffer and make/reinstall your kernel. I don't have a VESA framebuffer enabled. Only tdfx.o. > -- > Cheers, Gene > AMD K6-III@500mhz 320M > Athlon1600XP@1400mhz 512M > 99.22% setiathome rank, not too shabby for a WV hillbilly > Yahoo.com attornies please note, additions to this message > by Gene Heskett are: > Copyright 2003 by Maurice Eugene Heskett, all rights reserved. > > -- Jabber: heimdal@jabber.org ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 7:02 ` Andreas Jellinghaus 2003-12-09 7:13 ` Murray J. Root @ 2003-12-09 8:32 ` Greg KH 2003-12-09 9:59 ` Jan Dittmer 2003-12-10 2:15 ` Clemens Schwaighofer 1 sibling, 2 replies; 103+ messages in thread From: Greg KH @ 2003-12-09 8:32 UTC (permalink / raw) To: Andreas Jellinghaus; +Cc: linux-kernel On Tue, Dec 09, 2003 at 08:02:19AM +0100, Andreas Jellinghaus wrote: > On Tue, 2003-12-09 at 00:34, Greg KH wrote: > > You have 15 floppy devices connected to your box? All floppy devices > > should show up in /sys/block. > > No, 16 devices are normal, sysfs has only one: > aj@simulacron:~/torrent/j-tv/download$ ls /dev/floppy/ > 0 0u1120 0u1600 0u1722 0u1760 0u1920 0u720 0u820 > 0u1040 0u1440 0u1680 0u1743 0u1840 0u360 0u800 0u830 > aj@simulacron:~/torrent/j-tv/download$ find /sys/block/fd* -name dev > /sys/block/fd0/dev > > Are those floppy devices obsolete? fdformat was the only app to use > them anyway, I guess. (Not that I use my floppy, I simply noticed > the change.) I don't know if they are obsolete or not. I've never used them, and trying to figure out the floppy driver just makes my head hurt. I'm sure that if anyone really does use them, and udev doesn't work for them, I'll hear about it :) > > Regardless of the state of udev, devfs has insolvable problems and you > > should not use it. End of story. > > how many bug reports did you see in the last three months of people > having problems with devfs? I don't think that all 4 users of devfs on 2.6 are all that vocal :) Either way, I haven't been paying attention, as I really don't care. > I don't doubt the problems in theory, but but I simply haven't seen > them happening. Most users seem quite happy. There's no accounting for taste, is there. Anyway, sure some users might be happy, but when the kernel vfs maintainer shows that it's pretty simple to deadlock your kernel, and when the devfs maintainer disappears from view for over a year, that might be a good indication that you might want to stop using it. Besides, there's only one "major" distro still using devfs, and that's just because they don't know any better. thanks, greg k-h /me prepares for another onslaught of complaints from Gentoo users ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 8:32 ` State of devfs in 2.6? Greg KH @ 2003-12-09 9:59 ` Jan Dittmer 2003-12-09 13:54 ` Matthew Reppert 2003-12-09 16:27 ` Greg KH 2003-12-10 2:15 ` Clemens Schwaighofer 1 sibling, 2 replies; 103+ messages in thread From: Jan Dittmer @ 2003-12-09 9:59 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote: | On Tue, Dec 09, 2003 at 08:02:19AM +0100, Andreas Jellinghaus wrote: | |>>Regardless of the state of udev, devfs has insolvable problems and you |>>should not use it. End of story. |> |>how many bug reports did you see in the last three months of people |>having problems with devfs? | | | I don't think that all 4 users of devfs on 2.6 are all that vocal :) | Either way, I haven't been paying attention, as I really don't care. | FWIW, I've been using devfs from the beginning of 2.4 and with 2.5/2.6 with Debian and never had a problem (knock on wood). I really like the way of having device nodes only for present devices. Btw. I still haven't figured out, how to use udev properly. I just get the nodes of devices I plugin after boot and of the modules I load after boot. IDE et all aren't showing up. How early do I need to load udev or has my kernel to be all modular for it to work properly? Thanks, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/1ZztLqMJRclVKIYRAlgWAJ0cFbRv2QbWrQbFNWACwHrp/opQiQCfZJVD UjI7PkOYwt4auQb1qTRtwx8= =40wq -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 9:59 ` Jan Dittmer @ 2003-12-09 13:54 ` Matthew Reppert 2003-12-09 16:27 ` Greg KH 1 sibling, 0 replies; 103+ messages in thread From: Matthew Reppert @ 2003-12-09 13:54 UTC (permalink / raw) To: Jan Dittmer; +Cc: Greg KH, linux-kernel On Tue, 2003-12-09 at 03:59, Jan Dittmer wrote: > > Btw. I still haven't figured out, how to use udev properly. I just get > the nodes of devices I plugin after boot and of the modules I load after > boot. IDE et all aren't showing up. How early do I need to load udev or > has my kernel to be all modular for it to work properly? Since, I believe, version 006, udev has shipped with an init script contributed by rml that will create device nodes for devices present at system boot. You should be able to just make sure that that runs during your boot sequence and be fine. (I just ran this script on my system, and made sure it proper nodes for all my IDE drives and the partitions contained thereon.) Matt ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 9:59 ` Jan Dittmer 2003-12-09 13:54 ` Matthew Reppert @ 2003-12-09 16:27 ` Greg KH 2003-12-09 16:47 ` Eduard Bloch 1 sibling, 1 reply; 103+ messages in thread From: Greg KH @ 2003-12-09 16:27 UTC (permalink / raw) To: Jan Dittmer; +Cc: linux-kernel On Tue, Dec 09, 2003 at 10:59:09AM +0100, Jan Dittmer wrote: > Btw. I still haven't figured out, how to use udev properly. I just get > the nodes of devices I plugin after boot and of the modules I load after > boot. IDE et all aren't showing up. How early do I need to load udev or > has my kernel to be all modular for it to work properly? Like Matthew stated, either use the udev rc startup script, or put udev into your initramfs image to catch all of the early boot messages. Doing the initramfs method is still very tough to do right now, but people have reported success that way. I still recommend just using the init.d script for now. Oh, and if you do have any udev problems, please post them to the linux-hotplug-devel mailing list. thanks, greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 16:27 ` Greg KH @ 2003-12-09 16:47 ` Eduard Bloch 2003-12-09 19:33 ` Greg KH 0 siblings, 1 reply; 103+ messages in thread From: Eduard Bloch @ 2003-12-09 16:47 UTC (permalink / raw) To: linux-kernel #include <hallo.h> * Greg KH [Tue, Dec 09 2003, 08:27:47AM]: > Like Matthew stated, either use the udev rc startup script, or put udev > into your initramfs image to catch all of the early boot messages. > Doing the initramfs method is still very tough to do right now, but > people have reported success that way. I still recommend just using the > init.d script for now. Wouln't it be less error-prone to introduce a kind of queing for the hotplug program so kernel puts all the registered devices in a list and the list is submitted in one pass when udev asks for it? MfG, Eduard. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 16:47 ` Eduard Bloch @ 2003-12-09 19:33 ` Greg KH 0 siblings, 0 replies; 103+ messages in thread From: Greg KH @ 2003-12-09 19:33 UTC (permalink / raw) To: Eduard Bloch; +Cc: linux-kernel On Tue, Dec 09, 2003 at 05:47:39PM +0100, Eduard Bloch wrote: > #include <hallo.h> > * Greg KH [Tue, Dec 09 2003, 08:27:47AM]: > > > Like Matthew stated, either use the udev rc startup script, or put udev > > into your initramfs image to catch all of the early boot messages. > > Doing the initramfs method is still very tough to do right now, but > > people have reported success that way. I still recommend just using the > > init.d script for now. > > Wouln't it be less error-prone to introduce a kind of queing for the > hotplug program so kernel puts all the registered devices in a list and > the list is submitted in one pass when udev asks for it? Heh, no. It's much easier to just run out of early userspace. But that's just my opinion, if you think differently, I'd be very glad to see the code for your solution. :) thanks, greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-09 8:32 ` State of devfs in 2.6? Greg KH 2003-12-09 9:59 ` Jan Dittmer @ 2003-12-10 2:15 ` Clemens Schwaighofer 2003-12-10 4:10 ` Bob 1 sibling, 1 reply; 103+ messages in thread From: Clemens Schwaighofer @ 2003-12-10 2:15 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote: | | I don't think that all 4 users of devfs on 2.6 are all that vocal :) | Either way, I haven't been paying attention, as I really don't care. well ... I think there are more devfs users out there. eg, all the Gentoo freaks (me included) are sort of forced into devfs. If they want or not. And they will stick to it, until sysfs/udev/hotplug/foobarfs is so solid it can replace devfs. - -- Clemens Schwaighofer - IT Engineer & System Administration ========================================================== Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343 http://www.tequila.jp ========================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/1oHQjBz/yQjBxz8RAuumAJ9y5mXjaMSSOA0D3HL9g0pz0wSYkACfW0NC OqFAQbBoSAdGJwciCJuPsck= =MIoV -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-10 2:15 ` Clemens Schwaighofer @ 2003-12-10 4:10 ` Bob 0 siblings, 0 replies; 103+ messages in thread From: Bob @ 2003-12-10 4:10 UTC (permalink / raw) To: linux-kernel Skip to Bottom line: Does devfs do devpts on 2.6? Didn't for me. Clemens Schwaighofer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Greg KH wrote: > > | > | I don't think that all 4 users of devfs on 2.6 are all that vocal :) > | Either way, I haven't been paying attention, as I really don't care. > > well ... I think there are more devfs users out there. eg, all the > Gentoo freaks (me included) are sort of forced into devfs. If they want > or not. And they will stick to it, until sysfs/udev/hotplug/foobarfs is > so solid it can replace devfs. I'm using devfs on 2.6.0-test11. I have never run into the impossible to fix problems. I run devfs with very little old compatible naming. I edited /etc/devfs/compat_symlinks to give me /dev/sd* /dev/hd* and weirdly ln -s /dev/dsp2 /dev/dsp since all sound apps only seem to look for /dev/dsp which is only a dummy with nforce2. In 2.6 devfs would not do devpts for X so I put devpts back in the kernel and instantly got on with my work. I'm not sure if that means devfs can't do devpts in 2.6. I don't care. I see no devfs devices for a 32-bit cardbus pcmcia controller pci card which is id'd by yenta and cardmgr(pcmcia-cs v3.2.5), so I am switching to sysfs udev hotplug to see if that helps. Actually I can mount sysfs to /sys now and look around first but proc and var agree there is nada but there are two cards in slots. In the cdrecord thread Linus said some things about target/bus/lun naming and I must admit that it is nice to get back where ls /dev shows what drives there are without having to tree out into /dev/scsi/host/bus/target/lun/* to see how drives are recognized. That can be improved in most configurations by using compat symlinks instructions for /dev/sd* in /etc/devfs/compat_symlinks but as Linus explained iscsi handled better by sysfs udev /dev/s?? and not 0,0,0 targbuslun cdrecord-style. I like devfs and haven't ever had an error burning cd's with ide-scsi but I'm switching to udev and ide-cd to suck up to Linus before I start plaguing him about my pcmcia controller and yenta not working together--udev might work better with hotplug than devfs so I should try that first. It seems dubious that Gooch isn't maintaining devfs and syfs could be moving away from compatibility with devfs, and there are proven impossibilities about the devfs way. Devfs is a lot less broken than windows, though. Devfs might be good enough to Walmart-Microsoft pretty good alright rip the guts out of userland, but that's not good enough for the os that runs the internet. -Bob ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 23:34 ` Greg KH ` (3 preceding siblings ...) 2003-12-09 7:02 ` Andreas Jellinghaus @ 2003-12-09 7:33 ` Vojtech Pavlik 2003-12-09 9:48 ` Andreas Jellinghaus 5 siblings, 0 replies; 103+ messages in thread From: Vojtech Pavlik @ 2003-12-09 7:33 UTC (permalink / raw) To: Greg KH; +Cc: Andreas Jellinghaus, linux-kernel On Mon, Dec 08, 2003 at 03:34:28PM -0800, Greg KH wrote: > > - 5 input/ devices > > Patch for sysfs support for this has been posted by Hanna Linder. It > still needs work before being added to the kernel tree. I missed it. Where can I find it? -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 23:34 ` Greg KH ` (4 preceding siblings ...) 2003-12-09 7:33 ` Vojtech Pavlik @ 2003-12-09 9:48 ` Andreas Jellinghaus 5 siblings, 0 replies; 103+ messages in thread From: Andreas Jellinghaus @ 2003-12-09 9:48 UTC (permalink / raw) To: linux-kernel Greg, what about adding those patches to the hotplug utils directory, so people can find them easily and test sysfs+udev on empty /dev directories? Regards, Andreas ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? 2003-12-08 15:36 State of devfs in 2.6? Andrew Walrond 2003-12-08 15:42 ` William Lee Irwin III @ 2003-12-08 23:35 ` Greg KH 1 sibling, 0 replies; 103+ messages in thread From: Greg KH @ 2003-12-08 23:35 UTC (permalink / raw) To: Andrew Walrond; +Cc: linux-kernel On Mon, Dec 08, 2003 at 03:36:26PM +0000, Andrew Walrond wrote: > Whats the general feeling about devfs now? I remember Christoph and others > making some nasty remarks about it 6months ago or so, but later noted > christoph doing some slashing and burning thereof. > > Is it 'nice' yet? The kernel code is nicer, but is is marked OBSOLETE. It also has insolvalble race conditions that have been detailed many times here on lkml in the past. Please search the archives for more info. thanks, greg k-h ^ permalink raw reply [flat|nested] 103+ messages in thread
[parent not found: <10vOq-7mK-11@gated-at.bofh.it>]
[parent not found: <10vON-7mK-29@gated-at.bofh.it>]
[parent not found: <10CGd-1SM-39@gated-at.bofh.it>]
[parent not found: <10DiJ-2Qj-17@gated-at.bofh.it>]
[parent not found: <10Kas-8kr-3@gated-at.bofh.it>]
[parent not found: <10Kka-dD-11@gated-at.bofh.it>]
[parent not found: <10LJg-3zb-9@gated-at.bofh.it>]
[parent not found: <10LT5-3Wo-13@gated-at.bofh.it>]
[parent not found: <10N8i-7bE-1@gated-at.bofh.it>]
* Re: State of devfs in 2.6? [not found] ` <10N8i-7bE-1@gated-at.bofh.it> @ 2003-12-09 16:22 ` Pascal Schmidt 0 siblings, 0 replies; 103+ messages in thread From: Pascal Schmidt @ 2003-12-09 16:22 UTC (permalink / raw) To: Holger Schurig; +Cc: linux-kernel On Tue, 09 Dec 2003 11:20:06 +0100, you wrote in linux.kernel: > # find /dev | wc -l > 326 40k on ext2 (128 byte inodes). I'm betting devfs is more than 40k of code. Plus devfs uses more memory than a filesystem-backed /dev, don't you think? -- Ciao, Pascal ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: State of devfs in 2.6? @ 2003-12-09 18:50 Svetoslav Slavtchev 0 siblings, 0 replies; 103+ messages in thread From: Svetoslav Slavtchev @ 2003-12-09 18:50 UTC (permalink / raw) To: linux-kernel Hi sorry for using this kind of reply, but i'm not subscribed to lkml /* it would be nice if you CC me :-) */ ------ original e-mail ----------- On Mon, Dec 08, 2003 at 11:26:17PM -0600, Rob Landley wrote: > > Is there a big rollup patch against that adds all the sys/*/dev entries for > people who want to try udev? After I get finished catching up on USB patches that people sent me for the last month, I'll generate this and post it to lkml. thanks, greg k-h -------end original e-mail ----- Greg could you please post them splited, i'm having some issues with the one that adds misc devices -- oopses in early boot as described in http://marc.theaimsgroup.com/?l=linux-kernel&m=107097871212256&w=2 i managed to find 4 of the patches, but i'm still missing the ones for sound, input, parport the ones i found are available from the mandrake ml :-) eg http://marc.theaimsgroup.com/?l=mandrake-cooker&m=107099351100451&w=2 ( mem, vcs, fb , misc devices support) best, svetljo -- +++ GMX - die erste Adresse für Mail, Message, More +++ Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net ^ permalink raw reply [flat|nested] 103+ messages in thread
end of thread, other threads:[~2003-12-15 11:23 UTC | newest] Thread overview: 103+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-12-08 15:36 State of devfs in 2.6? Andrew Walrond 2003-12-08 15:42 ` William Lee Irwin III 2003-12-08 15:59 ` Andrew Walrond 2003-12-08 23:38 ` Greg KH 2003-12-09 10:37 ` Andrew Walrond 2003-12-09 10:57 ` Måns Rullgård 2003-12-09 12:54 ` Paul P Komkoff Jr 2003-12-09 5:04 ` Rob Landley 2003-12-08 19:09 ` udev sysfs docs " Bob 2003-12-08 23:37 ` Greg KH 2003-12-09 5:17 ` Witukind 2003-12-09 7:21 ` Bob 2003-12-09 7:39 ` Matthew Reppert 2003-12-09 8:52 ` Måns Rullgård 2003-12-09 9:16 ` Greg KH 2003-12-09 9:45 ` Måns Rullgård 2003-12-09 9:18 ` Greg KH 2003-12-09 9:46 ` Andreas Jellinghaus 2003-12-09 10:25 ` Måns Rullgård 2003-12-09 15:28 ` Andreas Jellinghaus 2003-12-09 20:16 ` Oliver Hunt 2003-12-09 20:53 ` Måns Rullgård 2003-12-09 22:14 ` Olaf Hering 2003-12-09 22:46 ` Oliver Hunt 2003-12-09 23:03 ` Måns Rullgård 2003-12-09 7:56 ` Greg KH 2003-12-09 9:00 ` Xavier Bestel 2003-12-09 9:08 ` Greg KH 2003-12-09 9:19 ` Miles Bader 2003-12-09 9:39 ` Måns Rullgård 2003-12-09 11:01 ` Helge Hafting 2003-12-12 11:26 ` Jamie Lokier 2003-12-12 13:33 ` Duncan Sands 2003-12-12 14:51 ` Jamie Lokier 2003-12-12 16:34 ` Chuck Campbell 2003-12-12 17:13 ` Chris Friesen 2003-12-12 17:17 ` Måns Rullgård 2003-12-15 2:12 ` Miles Bader 2003-12-15 3:51 ` Mark Mielke 2003-12-15 6:09 ` Tim Connors 2003-12-10 19:23 ` Witukind 2003-12-10 19:33 ` Måns Rullgård 2003-12-10 20:22 ` Witukind 2003-12-10 20:47 ` Ed Sweetman 2003-12-10 20:53 ` Ed Sweetman 2003-12-10 21:31 ` Witukind 2003-12-10 21:28 ` Witukind 2003-12-10 21:48 ` Måns Rullgård 2003-12-11 6:31 ` Witukind 2003-12-10 21:49 ` Måns Rullgård 2003-12-10 23:48 ` Maciej Zenczykowski 2003-12-11 1:53 ` Mark Mielke 2003-12-11 8:42 ` Måns Rullgård 2003-12-11 16:33 ` Mark Mielke 2003-12-10 20:48 ` Måns Rullgård 2003-12-10 23:40 ` Maciej Zenczykowski 2003-12-09 9:55 ` Xavier Bestel 2003-12-09 13:03 ` Maciej Zenczykowski 2003-12-09 15:01 ` Helge Hafting 2003-12-09 18:30 ` Greg KH 2003-12-09 18:53 ` Måns Rullgård 2003-12-10 7:02 ` Xavier Bestel 2003-12-10 20:06 ` Witukind 2003-12-11 9:27 ` Xavier Bestel 2003-12-11 10:15 ` Måns Rullgård 2003-12-11 11:05 ` Xavier Bestel 2003-12-10 0:38 ` Greg KH 2003-12-09 9:26 ` Måns Rullgård 2003-12-09 9:41 ` Miles Bader 2003-12-10 8:13 ` Jakob Oestergaard 2003-12-10 8:24 ` Rob Landley 2003-12-08 23:04 ` Andreas Jellinghaus 2003-12-08 23:34 ` Greg KH 2003-12-09 0:31 ` Sven-Haegar Koch 2003-12-09 0:42 ` Greg KH 2003-12-09 0:51 ` [PATCH] sysfs support for vcs devices (was Re: State of devfs in 2.6?) Greg KH 2003-12-09 5:26 ` State of devfs in 2.6? Rob Landley 2003-12-09 18:19 ` Greg KH 2003-12-09 18:20 ` Greg KH 2003-12-09 7:02 ` Andreas Jellinghaus 2003-12-09 7:13 ` Murray J. Root 2003-12-09 8:21 ` Holger Schurig 2003-12-09 8:52 ` Miles Bader 2003-12-09 10:08 ` Holger Schurig 2003-12-09 17:10 ` Mark Mielke 2003-12-10 5:42 ` Greg KH 2003-12-10 23:29 ` jw schultz 2003-12-11 20:32 ` [2.4.23] cursor dissapears in framebuffer console after switching back from X Witukind 2003-12-11 23:59 ` Gene Heskett 2003-12-12 6:24 ` Witukind 2003-12-09 8:32 ` State of devfs in 2.6? Greg KH 2003-12-09 9:59 ` Jan Dittmer 2003-12-09 13:54 ` Matthew Reppert 2003-12-09 16:27 ` Greg KH 2003-12-09 16:47 ` Eduard Bloch 2003-12-09 19:33 ` Greg KH 2003-12-10 2:15 ` Clemens Schwaighofer 2003-12-10 4:10 ` Bob 2003-12-09 7:33 ` Vojtech Pavlik 2003-12-09 9:48 ` Andreas Jellinghaus 2003-12-08 23:35 ` Greg KH [not found] <10vOq-7mK-11@gated-at.bofh.it> [not found] ` <10vON-7mK-29@gated-at.bofh.it> [not found] ` <10CGd-1SM-39@gated-at.bofh.it> [not found] ` <10DiJ-2Qj-17@gated-at.bofh.it> [not found] ` <10Kas-8kr-3@gated-at.bofh.it> [not found] ` <10Kka-dD-11@gated-at.bofh.it> [not found] ` <10LJg-3zb-9@gated-at.bofh.it> [not found] ` <10LT5-3Wo-13@gated-at.bofh.it> [not found] ` <10N8i-7bE-1@gated-at.bofh.it> 2003-12-09 16:22 ` Pascal Schmidt 2003-12-09 18:50 Svetoslav Slavtchev
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).