Re: devfs and udev

Re: devfs and udev

[Bradley Chapman]

Mr. Rullgard,

> I noticed this in the help text for devfs in 2.6.0-test6:
>
> Note that devfs has been obsoleted by udev,
> <http://www.kernel.org/pub/linux/utils/kernel/hotplug/>.
> It has been stripped down to a bare minimum and is only provided for
> legacy installations that use its naming scheme which is
> unfortunately different from the names normal Linux installations
> use.
> 
> Now, this puzzles me, for a few of reasons. Firstly, not long ago,
> devfs was spoken of as the way to go, and all drivers were rewritten
> to support it. Why this sudden change? Secondly, that link only
> leads me to a package describing itself as an experimental
> proof-of-concept thing, not to be used for anything serious. How can
> something that incomplete obsolete a working system like devfs?
> Thirdly, udev appears to respond to hotplug events only. How is it
> supposed to handle device files not corresponding to any physical
> device? Finally, I quite liked the idea of a virtual filesystem for
> /dev. It reduced the clutter quite a bit. As for the naming scheme,
> it could easily be changed.

I think the two things which really prevented devfs from working were:

1. The namespace was too different from the original and required additional
configuration to maintain compatibility (devfsd and changes to core /etc
files.)
2. Devfs was not immediately picked up my the major distros, which meant that
any moderate end-user who wanted to use it would have to be careful when
setting it up or risk massive core breakage due to the changed device nodes
(initscripts failing and the like).

I used it for a very long time, personally; it was a good idea, and it had
potential. If the namespace that had been used was the same flat namespace as
the original /dev, it would have probably taken off. As it is, I think udev
is the new way of doing this (I haven't used it yet).

Brad

=====
Brad Chapman

Permanent e-mail: kakadu_croc@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: devfs and udev

[Måns Rullgård]

Bradley Chapman <kakadu_croc@yahoo.com> writes:

> I think the two things which really prevented devfs from working were:

It's always worked just fine for me.

> 1. The namespace was too different from the original and required additional
> configuration to maintain compatibility (devfsd and changes to core /etc
> files.)

Since when do Linux developers resist changes?

> 2. Devfs was not immediately picked up my the major distros, which meant that
> any moderate end-user who wanted to use it would have to be careful when
> setting it up or risk massive core breakage due to the changed device nodes
> (initscripts failing and the like).

Had it been pushed harder, they probably would have done it.

> I used it for a very long time, personally; it was a good idea, and it had
> potential. If the namespace that had been used was the same flat namespace as
> the original /dev, it would have probably taken off. As it is, I think udev
> is the new way of doing this (I haven't used it yet).

The different naming was one thing i liked about devfs.  Go read the
archives from a couple of years ago, and see that the exact same
arguments that were used to promote devfs, are now said to be bad
things.  This sudden change is what I don't understand, and how the
not-working udev is supposed to be able to replace devfs.

-- 
Måns Rullgård
mru@users.sf.net

Re: devfs and udev

[insecure]

On Tuesday 07 October 2003 16:32, Måns Rullgård wrote:
> Bradley Chapman <kakadu_croc@yahoo.com> writes:
> > I think the two things which really prevented devfs from working were:
>
> It's always worked just fine for me.
>
> > 1. The namespace was too different from the original and required
> > additional configuration to maintain compatibility (devfsd and changes to
> > core /etc files.)
>
> Since when do Linux developers resist changes?
>
> > 2. Devfs was not immediately picked up my the major distros, which meant
> > that any moderate end-user who wanted to use it would have to be careful
> > when setting it up or risk massive core breakage due to the changed
> > device nodes (initscripts failing and the like).
>
> Had it been pushed harder, they probably would have done it.
>
> > I used it for a very long time, personally; it was a good idea, and it
> > had potential. If the namespace that had been used was the same flat
> > namespace as the original /dev, it would have probably taken off. As it
> > is, I think udev is the new way of doing this (I haven't used it yet).
>
> The different naming was one thing i liked about devfs.  Go read the
> archives from a couple of years ago, and see that the exact same
> arguments that were used to promote devfs, are now said to be bad
> things.  This sudden change is what I don't understand, and how the
> not-working udev is supposed to be able to replace devfs.

I am pro-devfs guy too.
If its internals are bad in some way or other, internals
may be fixed. But devfs userspace-visible interface was
not flawed (IMO).

What am I supposed to do, starting to use mknod again? Uggggh...
--
vda

Re: devfs and udev

[viro]

On Tue, Oct 07, 2003 at 09:28:09PM +0300, insecure wrote:
 
> I am pro-devfs guy too.
> If its internals are bad in some way or other, internals
> may be fixed. But devfs userspace-visible interface was
> not flawed (IMO).
> 
> What am I supposed to do, starting to use mknod again? Uggggh...

	Feel free to try and redesign the internals until they become
acceptable.  Since *nobody* had achieved that and those who'd tried
had generally come to conclusion that things is FUBAR...  Good luck,
but I'm not holding my breath.

Re: devfs and udev

[Greg KH]

On Tue, Oct 07, 2003 at 09:28:09PM +0300, insecure wrote:
> 
> What am I supposed to do, starting to use mknod again? Uggggh...

Provide me with a kernel name to devfs name mapping file so that I can
create a "devfs like" udev config file for people who happen to like
that naming scheme.

thanks,

greg k-h

Re: devfs and udev

[insecure]

On Tuesday 07 October 2003 22:41, Greg KH wrote:
> On Tue, Oct 07, 2003 at 09:28:09PM +0300, insecure wrote:
> > What am I supposed to do, starting to use mknod again? Uggggh...
>
> Provide me with a kernel name to devfs name mapping file so that I can
> create a "devfs like" udev config file for people who happen to like
> that naming scheme.

It seems that we have a bit of misunderstanding here.

I just don't want to go back to /dev being actually placed on
real, on-disk fs.

I won't mind if naming scheme will change as long
as device names start with '/dev/' and appear
there (semi-)automagically. That's what I call devfs.
If udev can do this, I am all for that.
-- 
vda

Re: devfs and udev

[Greg KH]

On Tue, Oct 07, 2003 at 11:47:41PM +0300, insecure wrote:
> On Tuesday 07 October 2003 22:41, Greg KH wrote:
> > On Tue, Oct 07, 2003 at 09:28:09PM +0300, insecure wrote:
> > > What am I supposed to do, starting to use mknod again? Uggggh...
> >
> > Provide me with a kernel name to devfs name mapping file so that I can
> > create a "devfs like" udev config file for people who happen to like
> > that naming scheme.
> 
> It seems that we have a bit of misunderstanding here.
> 
> I just don't want to go back to /dev being actually placed on
> real, on-disk fs.
> 
> I won't mind if naming scheme will change as long
> as device names start with '/dev/' and appear
> there (semi-)automagically. That's what I call devfs.
> If udev can do this, I am all for that.

udev can do this.  Is there some documentation that you read that has
suggested otherwise?

greg k-h

Re: devfs and udev

[David Lang]

On Tue, 7 Oct 2003, Bradley Chapman wrote:

> Date: Tue, 7 Oct 2003 06:17:19 -0700 (PDT)
> From: Bradley Chapman <kakadu_croc@yahoo.com>
> To: mru@users.sourceforge.net
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: devfs and udev
>
> Mr. Rullgard,
>
> > I noticed this in the help text for devfs in 2.6.0-test6:
> >
> > Note that devfs has been obsoleted by udev,
> > <http://www.kernel.org/pub/linux/utils/kernel/hotplug/>.
> > It has been stripped down to a bare minimum and is only provided for
> > legacy installations that use its naming scheme which is
> > unfortunately different from the names normal Linux installations
> > use.
> >
> > Now, this puzzles me, for a few of reasons. Firstly, not long ago,
> > devfs was spoken of as the way to go, and all drivers were rewritten
> > to support it. Why this sudden change? Secondly, that link only
> > leads me to a package describing itself as an experimental
> > proof-of-concept thing, not to be used for anything serious. How can
> > something that incomplete obsolete a working system like devfs?
> > Thirdly, udev appears to respond to hotplug events only. How is it
> > supposed to handle device files not corresponding to any physical
> > device? Finally, I quite liked the idea of a virtual filesystem for
> > /dev. It reduced the clutter quite a bit. As for the naming scheme,
> > it could easily be changed.
>
> I think the two things which really prevented devfs from working were:
>
> 1. The namespace was too different from the original and required additional
> configuration to maintain compatibility (devfsd and changes to core /etc
> files.)

the namespace was different becouse Linus demanded that it be different,
origionally it had a mode where it would generate all the same names (and
another mode that generated sun style names) one of the requirements
before it was put in was to change it to the existing devfs-only names.

blame devfs for a lot of things (bugs, etc) but not the names.

David Lang

> 2. Devfs was not immediately picked up my the major distros, which meant that
> any moderate end-user who wanted to use it would have to be careful when
> setting it up or risk massive core breakage due to the changed device nodes
> (initscripts failing and the like).
>
> I used it for a very long time, personally; it was a good idea, and it had
> potential. If the namespace that had been used was the same flat namespace as
> the original /dev, it would have probably taken off. As it is, I think udev
> is the new way of doing this (I haven't used it yet).
>
> Brad
>
> =====
> Brad Chapman
>
> Permanent e-mail: kakadu_croc@yahoo.com
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: devfs and udev

[Chris Meadors]

On Tue, 2003-10-07 at 16:52, Greg KH wrote:
> On Tue, Oct 07, 2003 at 11:47:41PM +0300, insecure wrote:
> > It seems that we have a bit of misunderstanding here.
> > 
> > I just don't want to go back to /dev being actually placed on
> > real, on-disk fs.
> > 
> > I won't mind if naming scheme will change as long
> > as device names start with '/dev/' and appear
> > there (semi-)automagically. That's what I call devfs.
> > If udev can do this, I am all for that.
> 
> udev can do this.  Is there some documentation that you read that has
> suggested otherwise?

Lets see if I can make this clear, devfs is a virtual file system.  If I
mount my root drive without mounting devfs, the /dev directory is
empty.  udev is not like this, it is like the normal /dev that can be
built with mknod, special files in a real filesystem.  But udev is told
by the kernel what files to make and remove.  So it is still a dynamic
filesystem, just in userland with kernel notifications rather than a
filesystem that is entirely in kernel space.

devfsd could use a "/dev-state" (or similar) directory to preserve the
state of any changes made to the virtual filesystem using normal
userland tools are mirrored in that directory.

I am also a huge devfs fan.  I was building 2.2.x kernels with Richard's
patches before 2.4.0 was released.  I like just having an empty /dev and
knowing the kernel will take care of everything I need at boot.

I'm thinking this will not exactly work with udev, as you will need a
few seed nodes to get to userland so udev can be started.  Then udev
will create the entries for devices that actually exist on the machine,
and then these entries will still be present at the next boot.  So it
will just be a problem for initial installs.

Right?

I can handle all of this.  I'm flexible.  Just make it work.  :)

-- 
Chris

Re: devfs and udev

[Måns Rullgård]

Greg KH <greg@kroah.com> writes:

>> > > What am I supposed to do, starting to use mknod again? Uggggh...
>> >
>> > Provide me with a kernel name to devfs name mapping file so that I can
>> > create a "devfs like" udev config file for people who happen to like
>> > that naming scheme.
>> 
>> It seems that we have a bit of misunderstanding here.
>> 
>> I just don't want to go back to /dev being actually placed on
>> real, on-disk fs.
>> 
>> I won't mind if naming scheme will change as long
>> as device names start with '/dev/' and appear
>> there (semi-)automagically. That's what I call devfs.
>> If udev can do this, I am all for that.
>
> udev can do this.  Is there some documentation that you read that has
> suggested otherwise?

It's been my understanding that udev creates device nodes in a regular
filesystem.  If this is the case, things like unclean reboots will
leave stale files behind.  It will also not be easy to
bootstrap. Correct me if am wrong.

-- 
Måns Rullgård
mru@users.sf.net

Re: devfs and udev

[Greg KH]

On Tue, Oct 07, 2003 at 11:27:37PM +0200, Måns Rullgård wrote:
> Greg KH <greg@kroah.com> writes:
> 
> >> > > What am I supposed to do, starting to use mknod again? Uggggh...
> >> >
> >> > Provide me with a kernel name to devfs name mapping file so that I can
> >> > create a "devfs like" udev config file for people who happen to like
> >> > that naming scheme.
> >> 
> >> It seems that we have a bit of misunderstanding here.
> >> 
> >> I just don't want to go back to /dev being actually placed on
> >> real, on-disk fs.
> >> 
> >> I won't mind if naming scheme will change as long
> >> as device names start with '/dev/' and appear
> >> there (semi-)automagically. That's what I call devfs.
> >> If udev can do this, I am all for that.
> >
> > udev can do this.  Is there some documentation that you read that has
> > suggested otherwise?
> 
> It's been my understanding that udev creates device nodes in a regular
> filesystem.  If this is the case, things like unclean reboots will
> leave stale files behind.  It will also not be easy to
> bootstrap. Correct me if am wrong.

mount -t ramfs none /dev

That is what udev will run off of :)

Again, can you point me to any documentation that states that udev will
do this on a persistant filesystem?

thanks,

greg k-h

Re: devfs and udev

[Greg KH]

On Tue, Oct 07, 2003 at 05:17:23PM -0400, Chris Meadors wrote:
> On Tue, 2003-10-07 at 16:52, Greg KH wrote:
> > On Tue, Oct 07, 2003 at 11:47:41PM +0300, insecure wrote:
> > > It seems that we have a bit of misunderstanding here.
> > > 
> > > I just don't want to go back to /dev being actually placed on
> > > real, on-disk fs.
> > > 
> > > I won't mind if naming scheme will change as long
> > > as device names start with '/dev/' and appear
> > > there (semi-)automagically. That's what I call devfs.
> > > If udev can do this, I am all for that.
> > 
> > udev can do this.  Is there some documentation that you read that has
> > suggested otherwise?
> 
> Lets see if I can make this clear, devfs is a virtual file system.

I know that, please give me some credit here.  I've used devfs before,
and rutted around in all of it's dirt for a long time.  It's not like
I'm suddenly creating some wild, hair brained scheme out of thin air
here.  I've been working toward this solution for a number of years now
(see the proposal from Pat Mochel and myself at the kernel summit two
years ago, and my 5 minute talk this year), and it hasn't exactly been
in private.  There have been a number of discussions in public places
(two different kernel summits, OLS papers, and lots of linux-kernel and
linux-hotplug-devel mail traffic), so this shouldn't be that much of a
shock to the devfs lovers out there.

And remember, _I_ did not submit that patch to the kernel marking devfs
obsolete.  Other kernel developers did.  And for good reasons, which
have all been explained before.  Even if udev wasn't even written yet,
it would have been done.

> If I mount my root drive without mounting devfs, the /dev directory is
> empty.  udev is not like this, it is like the normal /dev that can be
> built with mknod, special files in a real filesystem.  But udev is told
> by the kernel what files to make and remove.  So it is still a dynamic
> filesystem, just in userland with kernel notifications rather than a
> filesystem that is entirely in kernel space.

Again:
	mount -t ramfs none /dev

There, empty filesystem.  No persistance.  Happy?

> devfsd could use a "/dev-state" (or similar) directory to preserve the
> state of any changes made to the virtual filesystem using normal
> userland tools are mirrored in that directory.

See the OLS paper for how this will be handled.

> I am also a huge devfs fan.  I was building 2.2.x kernels with Richard's
> patches before 2.4.0 was released.  I like just having an empty /dev and
> knowing the kernel will take care of everything I need at boot.

Great.  I hope you have enjoyed your security problems, and race
conditions too.  :)

> I'm thinking this will not exactly work with udev, as you will need a
> few seed nodes to get to userland so udev can be started.  Then udev
> will create the entries for devices that actually exist on the machine,
> and then these entries will still be present at the next boot.  So it
> will just be a problem for initial installs.
> 
> Right?

Look at the boot process today.  We "seed" a ramfs with some initial
/dev entries in order to boot the kernel from initramfs.  udev will take
off from there and keep creating new entries as devices are discovered,
long before init and the rest of userspace starts up.

> I can handle all of this.  I'm flexible.  Just make it work.  :)

Patches are always gladly accepted.


People, come on, please read the existing documentation before coming up
with some half-baked ideas about what udev is.  Yes, there is a gap with
the existing documentation, and some people have very nicely pointed
this out.  But if I have to spend my time answering questions that are
already answered, I'll never have the time to flush out these gaps, and
actually do some udev programming...

greg k-h

Re: devfs and udev

[Måns Rullgård]

Greg KH <greg@kroah.com> writes:

>> It's been my understanding that udev creates device nodes in a regular
>> filesystem.  If this is the case, things like unclean reboots will
>> leave stale files behind.  It will also not be easy to
>> bootstrap. Correct me if am wrong.
>
> mount -t ramfs none /dev
>
> That is what udev will run off of :)

There will still have to be some static device files to get the system
booted, right?  init usually is rather unhappy if it can't find
/dev/console.

> Again, can you point me to any documentation that states that udev will
> do this on a persistant filesystem?

Can you point me to any documentation at all?

-- 
Måns Rullgård
mru@users.sf.net

Re: devfs and udev

[Bryan O'Sullivan]

On Tue, 2003-10-07 at 15:01, Måns Rullgård wrote:

> There will still have to be some static device files to get the system
> booted, right?  init usually is rather unhappy if it can't find
> /dev/console.

There are the necessary few in initramfs already.

> Can you point me to any documentation at all?

Really, I don't know why Greg is bothering to answer your questions.

This stuff is all readily accessible via (a) getting off your nethers
and doing a Google search for "linux udev" and (b) reading what you
find.  It's trivial to find, and it's utterly obvious how it works.

Sheesh.

	<b

Re: devfs and udev

[Måns Rullgård]

Bryan O'Sullivan <bos@serpentine.com> writes:

>> Can you point me to any documentation at all?
>
> Really, I don't know why Greg is bothering to answer your questions.
>
> This stuff is all readily accessible via (a) getting off your nethers
> and doing a Google search for "linux udev" and (b) reading what you
> find.  It's trivial to find, and it's utterly obvious how it works.

I followed the link provided in the Kconfig, and downloaded the files
that seemed reasonable.  The only documentation I found there warned
me against using it.

-- 
Måns Rullgård
mru@users.sf.net

Re: devfs and udev

[Greg KH]

On Wed, Oct 08, 2003 at 12:49:41AM +0200, Måns Rullgård wrote:
> Bryan O'Sullivan <bos@serpentine.com> writes:
> 
> >> Can you point me to any documentation at all?
> >
> > Really, I don't know why Greg is bothering to answer your questions.
> >
> > This stuff is all readily accessible via (a) getting off your nethers
> > and doing a Google search for "linux udev" and (b) reading what you
> > find.  It's trivial to find, and it's utterly obvious how it works.
> 
> I followed the link provided in the Kconfig, and downloaded the files
> that seemed reasonable.  The only documentation I found there warned
> me against using it.

Then don't use it, no one is forcing you to.

But if you do, wow, look at the second Google link for "linux udev":
	http://www.ussg.iu.edu/hypermail/linux/kernel/0307.3/0495.html

Hey look, documentation, a presentation, and wow, a statement saying
that the code sucks, and is merely a proof of concept, and that it will
get better over time.  That's a zillion lines more of text than most
open source projects ever generate.

{sigh}

greg k-h

Re: devfs and udev

[Måns Rullgård]

Greg KH <greg@kroah.com> writes:

> Hey look, documentation, a presentation, and wow, a statement saying
> that the code sucks, and is merely a proof of concept, and that it will

I never meant to say that udev never will be a viable solution.  I
also understand now that devfs has problems that nobody is willing
solve.  Thus the marking as obsolete may be justified.  However, the
statement that it has been obsoleted *by* udev, is, IMHO, a little
bold.

-- 
Måns Rullgård
mru@users.sf.net

Re: devfs and udev

[Andreas Jellinghaus]

On Tue, 07 Oct 2003 21:51:27 +0000, Greg KH wrote:
> And remember, _I_ did not submit that patch to the kernel marking devfs
> obsolete.  Other kernel developers did.  And for good reasons, which
> have all been explained before.  Even if udev wasn't even written yet,
> it would have been done.

"Note that devfs has been obsoleted by udev,"

Most people expect after reading that sentence, that udev can do the
work devfs did for them. But udev is not ready to do that, even by
far. Thats why people complain.

Also all the documentation you mention doesn't help very much:
if someone wants to sit down, use devfs, even improve some parts
of the kernel with sysfs support, so sysfs will show all devices -
there is no documentation or example how to do that. The whole
kobject / sysfs / driver model code is by far not as easy to
understand as those devfs function calls are.

> Patches are always gladly accepted.

How can we patch udev, if sysfs doesn't seem to have the necessary
information. for example devfs has disc, floppy, cdrom. sysfs has only
/sys/block/hd*. Sorry, but I don't see how udev can create a result like
devfs did, without the necessary information in /sys. And the kernel
code isn't easy.

> People, come on, please read the existing documentation

show me that I'm wrong, and those questions I asked are documented,
and I will be happy and appologize. But I'm very sorry: even reading
your papers a hundred times doesn't show how drivers are supposed to
create custom entries for more devices. With devfs it's a five minute
look at a few drivers like floppy.c and printers.c and you get the idea.

Also the documentation is actualy confusing: why is a usb printer put
into class "usb" and not class printer? Why does udev decide the type
of device by matching /sys/block, why not export that data explicit?
Why not export default permissions, like devfs does?

With some answers, we might understand udev and sysfs better and might
be able to help. But asking for patches is not going to work, if basic
questions are left without answers.

Regards, Andreas

[2.6 patch] document that udev isn't yet ready

[Adrian Bunk]

On Wed, Oct 08, 2003 at 09:30:21AM +0200, Andreas Jellinghaus wrote:
> On Tue, 07 Oct 2003 21:51:27 +0000, Greg KH wrote:
> > And remember, _I_ did not submit that patch to the kernel marking devfs
> > obsolete.  Other kernel developers did.  And for good reasons, which
> > have all been explained before.  Even if udev wasn't even written yet,
> > it would have been done.
> 
> "Note that devfs has been obsoleted by udev,"
> 
> Most people expect after reading that sentence, that udev can do the
> work devfs did for them. But udev is not ready to do that, even by
> far. Thats why people complain.
>...

The following trivial change to te help text should clarify it:

--- linux-2.6.0-test6-mm4/fs/Kconfig.old	2003-10-08 14:02:15.000000000 +0200
+++ linux-2.6.0-test6-mm4/fs/Kconfig	2003-10-08 14:03:33.000000000 +0200
@@ -784,7 +784,7 @@
 	  ptys, you will also need to enable (and mount) the /dev/pts
 	  filesystem (CONFIG_DEVPTS_FS).
 
-	  Note that devfs has been obsoleted by udev,
+	  Note that devfs will be obsoleted by udev
 	  <http://www.kernel.org/pub/linux/utils/kernel/hotplug/>.
 	  It has been stripped down to a bare minimum and is only provided for
 	  legacy installations that use its naming scheme which is


> Regards, Andreas

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: devfs and udev

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.58.0310071354580.19220@dlang.diginsite.com>
By author:    David Lang <david.lang@digitalinsight.com>
In newsgroup: linux.dev.kernel
> 
> the namespace was different becouse Linus demanded that it be different,
> origionally it had a mode where it would generate all the same names (and
> another mode that generated sun style names) one of the requirements
> before it was put in was to change it to the existing devfs-only names.
> 
> blame devfs for a lot of things (bugs, etc) but not the names.
> 

Actually, this is bullshit.  If you go back and look what Linus
actually said, it was:

- One namespace only.  If you're going to a new namespace, then that's
  going to be it.  You're not going to put two namespaces in the
  kernel.

- If you're going hierarcial, do it right, not the Sun-like halfassed
  thing.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: devfs and udev

[bill davidsen]

In article <20031007213758.GB3095@kroah.com>,
Greg KH  <linux-kernel@vger.kernel.org> wrote:

| mount -t ramfs none /dev
| 
| That is what udev will run off of :)
| 
| Again, can you point me to any documentation that states that udev will
| do this on a persistant filesystem?

I'm going back to look again, but I don't recall that it won't, either.
If it wants a ramfs on /dev, why doesn't it just create one? That's a
question, not an argument! I had assumed it would run on a persistent
f/s if present.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: devfs and udev

[Tom Rini]

On Thu, Oct 09, 2003 at 10:09:33PM +0000, bill davidsen wrote:
> In article <20031007213758.GB3095@kroah.com>,
> Greg KH  <linux-kernel@vger.kernel.org> wrote:
> 
> | mount -t ramfs none /dev
> | 
> | That is what udev will run off of :)
> | 
> | Again, can you point me to any documentation that states that udev will
> | do this on a persistant filesystem?
> 
> I'm going back to look again, but I don't recall that it won't, either.
> If it wants a ramfs on /dev, why doesn't it just create one? That's a
> question, not an argument! I had assumed it would run on a persistent
> f/s if present.

Whatever f/s udev runs on is independant of udev, it just runs.  Ideally
distros / packagers should set things up so that it runs on ramfs.

-- 
Tom Rini
http://gate.crashing.org/~trini/