State of devfs in 2.6?

State of devfs in 2.6?

[Andrew Walrond]

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

Re: State of devfs in 2.6?

[William Lee Irwin III]

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

Re: State of devfs in 2.6?

[Andrew Walrond]

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?

Re: State of devfs in 2.6?

[Greg KH]

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

Re: State of devfs in 2.6?

[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.

Andrew Walrond

Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: State of devfs in 2.6?

[Paul P Komkoff Jr]

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

Re: State of devfs in 2.6?

[Rob Landley]

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

udev sysfs docs Re: State of devfs in 2.6?

[Bob]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Greg KH]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Witukind]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Bob]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Matthew Reppert]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Greg KH]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Greg KH]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Andreas Jellinghaus]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Andreas Jellinghaus]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Oliver Hunt]

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...

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Olaf Hering]

 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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Oliver Hunt]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Greg KH]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Xavier Bestel]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Greg KH]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Miles Bader]

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.

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Helge Hafting]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Jamie Lokier]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Duncan Sands]

>     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.

Re: udev sysfs docs Re: State of devfs in 2.6?

[Jamie Lokier]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Chuck Campbell]

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

-- 

Re: udev sysfs docs Re: State of devfs in 2.6?

[Chris Friesen]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Miles Bader]

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....

Re: udev sysfs docs Re: State of devfs in 2.6?

[Mark Mielke]

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/

Re: udev sysfs docs Re: State of devfs in 2.6?

[Tim Connors]

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?

Re: udev sysfs docs Re: State of devfs in 2.6?

[Witukind]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Witukind]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Ed Sweetman]

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.

Re: udev sysfs docs Re: State of devfs in 2.6?

[Ed Sweetman]

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.
>

Re: udev sysfs docs Re: State of devfs in 2.6?

[Witukind]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Witukind]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Witukind]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Maciej Zenczykowski]

> 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.

Re: udev sysfs docs Re: State of devfs in 2.6?

[Mark Mielke]

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/

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Mark Mielke]

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/

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Maciej Zenczykowski]

> > 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.

Re: udev sysfs docs Re: State of devfs in 2.6?

[Xavier Bestel]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Maciej Zenczykowski]

> > > 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.

Re: udev sysfs docs Re: State of devfs in 2.6?

[Helge Hafting]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Greg KH]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Xavier Bestel]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Witukind]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Xavier Bestel]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Xavier Bestel]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Greg KH]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Måns Rullgård]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Miles Bader]

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]

Re: udev sysfs docs Re: State of devfs in 2.6?

[Jakob Oestergaard]

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

Re: udev sysfs docs Re: State of devfs in 2.6?

[Rob Landley]

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...)

Re: State of devfs in 2.6?

[Andreas Jellinghaus]

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

Re: State of devfs in 2.6?

[Greg KH]

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

Re: State of devfs in 2.6?

[Sven-Haegar Koch]

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/)

Re: State of devfs in 2.6?

[Greg KH]

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

[PATCH] sysfs support for vcs devices (was Re: State of devfs in 2.6?)

[Greg KH]

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;
 }

Re: State of devfs in 2.6?

[Rob Landley]

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

Re: State of devfs in 2.6?

[Greg KH]

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

Re: State of devfs in 2.6?

[Greg KH]

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

Re: State of devfs in 2.6?

[Andreas Jellinghaus]

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

Re: State of devfs in 2.6?

[Murray J. Root]

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

Re: State of devfs in 2.6?

[Holger Schurig]

>> 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/

Re: State of devfs in 2.6?

[Miles Bader]

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]

Re: State of devfs in 2.6?

[Holger Schurig]

>> * 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/

Re: State of devfs in 2.6?

[Mark Mielke]

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/

Re: State of devfs in 2.6?

[Greg KH]

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

Re: State of devfs in 2.6?

[jw schultz]

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

[2.4.23] cursor dissapears in framebuffer console after switching back from X

[Witukind]

[-- 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

Re: [2.4.23] cursor dissapears in framebuffer console after switching back from X

[Gene Heskett]

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.

Re: [2.4.23] cursor dissapears in framebuffer console after switching back from X

[Witukind]

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

Re: State of devfs in 2.6?

[Greg KH]

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 

Re: State of devfs in 2.6?

[Jan Dittmer]

-----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-----

Re: State of devfs in 2.6?

[Matthew Reppert]

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

Re: State of devfs in 2.6?

[Greg KH]

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

Re: State of devfs in 2.6?

[Eduard Bloch]

#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.

Re: State of devfs in 2.6?

[Greg KH]

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

Re: State of devfs in 2.6?

[Clemens Schwaighofer]

-----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-----

Re: State of devfs in 2.6?

[Bob]

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

Re: State of devfs in 2.6?

[Vojtech Pavlik]

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

Re: State of devfs in 2.6?

[Andreas Jellinghaus]

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

Re: State of devfs in 2.6?

[Greg KH]

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