Re: udev and devfs - The final word

Re: udev and devfs - The final word

[Pascal Schmidt]

On Wed, 31 Dec 2003 01:40:09 +0100, you wrote in linux.kernel:

>     2) udev does not care about the major/minor number schemes.  If the
>        kernel tomorrow switches to randomly assign major and minor numbers
>        to different devices, it would work just fine (this is exactly
>        what I am proposing to do in 2.7...)

Why? I want to keep my static device files in /dev. I don't even have
hotpluggable devices, and many months do pass before even one piece
of hardware gets changed (in which case I know what I have to do).
I don't want to eat any overhead or run any daemons or hotplug agents.

What benefit would there be in "random" numbers? More compressed number
space by giving out numbers sequentially? Or less having to work with
the numbers because they become just cookies and never need to be
inspected except in very small parts of the kernel?

-- 
Ciao,
Pascal

Re: udev and devfs - The final word

[Greg KH]

On Wed, Dec 31, 2003 at 04:05:59AM +0100, Pascal Schmidt wrote:
> On Wed, 31 Dec 2003 01:40:09 +0100, you wrote in linux.kernel:
> 
> >     2) udev does not care about the major/minor number schemes.  If the
> >        kernel tomorrow switches to randomly assign major and minor numbers
> >        to different devices, it would work just fine (this is exactly
> >        what I am proposing to do in 2.7...)
> 
> Why? I want to keep my static device files in /dev. I don't even have
> hotpluggable devices, and many months do pass before even one piece
> of hardware gets changed (in which case I know what I have to do).
> I don't want to eat any overhead or run any daemons or hotplug agents.

You would not have any "extra" overhead if you don't add any new devices
to your system.  udev only runs when /sbin/hotplug runs.  As for extra
space on your disk, this email thread is almost as big as the udev
binary is :)

> What benefit would there be in "random" numbers? More compressed number
> space by giving out numbers sequentially?

Yes.

> Or less having to work with the numbers because they become just
> cookies and never need to be inspected except in very small parts of
> the kernel?

That is already happening today in the kernel.  

And 2.8 will probably have the "random number" assignment be a compile
option, depending on the maturity of udev.  We'll just have to see how
it works out.

thanks,

greg k-h

Re: udev and devfs - The final word

[Rob Love]

On Wed, 2003-12-31 at 14:23, Greg KH wrote:

> What benefit would there be in "random" numbers? More compressed number
> space by giving out numbers sequentially?

That is one advantage.

> Or less having to work with the numbers because they become just
> cookies and never need to be inspected except in very small parts of
> the kernel?

Yup, especially this one.  It is not so much "let's make the device
numbers random" but "let's just not care what they are."

We can get to the point where we don't even need the explicit concept of
device numbers, but just "any old unique value" to use as a cookie.  The
kernel can pull that number from anywhere, and notify user-space via
udev ala hotplug.

	Rob Love

Re: udev and devfs - The final word

[Nathan Conrad]

One thing that I'm confused about with respect to device files is how
kernel arguments are supposed to work. Now, we _seem_ to have a
mish-mash of different ways to tell the kernel which device to open as
a console, which device to use as a suspend device, etc.... Now, all
of the device names are being migrated to userland. How is the kernel
supposed to determine which device to use when it is told use
/dev/hda3 or /dev/ide/host0/something/part3 as the suspend partition?
The kernel no longer knows to which device this string this device is
connected.

(I have not looked into how these parameters are parsed; this is pure
speculation)

One solution that I see if the device names are totally removed from
the kernel is specifying these parameters as sysfs paths. Would this
work? Or is there a better way?

-Nathan

On Wed, Dec 31, 2003 at 03:19:22PM -0500, Rob Love wrote:
> On Wed, 2003-12-31 at 14:23, Greg KH wrote:
> 
> > What benefit would there be in "random" numbers? More compressed number
> > space by giving out numbers sequentially?
> 
> That is one advantage.
> 
> > Or less having to work with the numbers because they become just
> > cookies and never need to be inspected except in very small parts of
> > the kernel?
> 
> Yup, especially this one.  It is not so much "let's make the device
> numbers random" but "let's just not care what they are."
> 
> We can get to the point where we don't even need the explicit concept of
> device numbers, but just "any old unique value" to use as a cookie.  The
> kernel can pull that number from anywhere, and notify user-space via
> udev ala hotplug.
> 
> 	Rob Love
> 
> 
> -
> 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/

-- 
Nathan J. Conrad                     Campus phone #5930
301 Scott hall, UNC Charlotte        http://bungled.net
GPG: F4FC 7E25 9308 ECE1 735C  0798 CE86 DA45 9170 3112

Re: udev and devfs - The final word

[Rob Love]

On Wed, 2003-12-31 at 17:01, Nathan Conrad wrote:

> One thing that I'm confused about with respect to device files is how
> kernel arguments are supposed to work. Now, we _seem_ to have a
> mish-mash of different ways to tell the kernel which device to open as
> a console, which device to use as a suspend device, etc.... Now, all
> of the device names are being migrated to userland. How is the kernel
> supposed to determine which device to use when it is told use
> /dev/hda3 or /dev/ide/host0/something/part3 as the suspend partition?
> The kernel no longer knows to which device this string this device is
> connected.

Uh, Unix systems (Linux included) do not use the filename of the device
node at all.  Those are just names for you, the user.

The kernel uses the device number to understand what device user-space
is trying to access.  The kernel associates the device with a device
number.  Normally that number is static, and known a priori, so we just
create a huge /dev directory with all possible devices and their
assigned numbers (you can see these numbers with ls -la).

But if the kernel _tells_ user-space what the device number is, for each
device as it is created, we do not need a static /dev directory.  We can
assemble the directory on the fly and device numbers really no longer
matter.  This is what udev does.

	Rob Love

Re: udev and devfs - The final word

[Tommi Virtanen]

Rob Love wrote:
>>One thing that I'm confused about with respect to device files is how
>>kernel arguments are supposed to work. Now, we _seem_ to have a
>>mish-mash of different ways to tell the kernel which device to open as
>>a console, which device to use as a suspend device, etc.... Now, all
>>of the device names are being migrated to userland. How is the kernel
>>supposed to determine which device to use when it is told use
>>/dev/hda3 or /dev/ide/host0/something/part3 as the suspend partition?
>>The kernel no longer knows to which device this string this device is
>>connected.
...

> The kernel uses the device number to understand what device user-space
> is trying to access.  The kernel associates the device with a device
> number.  Normally that number is static, and known a priori, so we just
> create a huge /dev directory with all possible devices and their
> assigned numbers (you can see these numbers with ls -la).

Let me try to rephrase Nathan's question more explicitly.

If user policy decides all naming, how does the kernel parse e.g. 
root=/dev/foo arguments? Or the swap partition to use for swsuspend?

Re: udev and devfs - The final word

[Rob Love]

On Wed, 2003-12-31 at 16:45, Tommi Virtanen wrote:

> Let me try to rephrase Nathan's question more explicitly.
> 
> If user policy decides all naming, how does the kernel parse e.g. 
> root=/dev/foo arguments? Or the swap partition to use for swsuspend?

Oh.  That has always been a hack, ala name_to_dev_t().

We will have to continue doing that hack so long as those users are in
the kernel proper (and not early user-space, for example).

	Rob Love

Re: udev and devfs - The final word

[Tommi Virtanen]

Rob Love wrote:
>>Let me try to rephrase Nathan's question more explicitly.
>>
>>If user policy decides all naming, how does the kernel parse e.g. 
>>root=/dev/foo arguments? Or the swap partition to use for swsuspend?
> Oh.  That has always been a hack, ala name_to_dev_t().
> 
> We will have to continue doing that hack so long as those users are in
> the kernel proper (and not early user-space, for example).

I think devfs names are accepted as root= arguments, so that's a bit of
a loss.. with udev, your /dev and your root= are equal only if you
follow the standard naming.

For root=, I can see how early userspace can move that to userspace.
But what about swsuspend?

Are there any more kernel options taking file names? I think now would
be a good time to stop adding more of them :)

Re: udev and devfs - The final word

[Hollis Blanchard]

On Wednesday, Dec 31, 2003, at 15:52 US/Central, Tommi Virtanen wrote:
> I think devfs names are accepted as root= arguments, so that's a bit of
> a loss.. with udev, your /dev and your root= are equal only if you
> follow the standard naming.
>
> For root=, I can see how early userspace can move that to userspace.
> But what about swsuspend?
>
> Are there any more kernel options taking file names? I think now would
> be a good time to stop adding more of them :)

"console=" takes driver-supplied names which usually happen to match 
/dev node names. For example, drivers/serial/8250.c names itself 
"ttyS", so "console=ttyS0" will end up going to that driver, regardless 
of the state of /dev.

I'm not saying that's good or bad, but what's the alternative? 
"console=class/tty/ttyS0"?

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: udev and devfs - The final word

[viro]

On Thu, Jan 01, 2004 at 06:17:43PM -0600, Hollis Blanchard wrote:
> "console=" takes driver-supplied names which usually happen to match 
> /dev node names. For example, drivers/serial/8250.c names itself 
> "ttyS", so "console=ttyS0" will end up going to that driver, regardless 
> of the state of /dev.
> 
> I'm not saying that's good or bad, but what's the alternative? 
> "console=class/tty/ttyS0"?

Console code will need serious work anyway; note that current names
do _not_ refer to tty devices - there is some overlap, but right now
we have
	* console drivers
	* some of them being connected with tty drivers; those can tell
which tty driver corresponds to them
	* console ouput code maintaining chain of console drivers; output
is sent to them, attempt to open() /dev/console ends up picking the first
console driver that has corresponding tty one (== has console->device())
and opening the tty device in question
	* unholy mess with redirects.

There's no device nodes for console drivers.  So names in console=... are
something very odd, indeed.

Re: udev and devfs - The final word

[Greg KH]

On Thu, Jan 01, 2004 at 06:17:43PM -0600, Hollis Blanchard wrote:
> On Wednesday, Dec 31, 2003, at 15:52 US/Central, Tommi Virtanen wrote:
> >I think devfs names are accepted as root= arguments, so that's a bit of
> >a loss.. with udev, your /dev and your root= are equal only if you
> >follow the standard naming.
> >
> >For root=, I can see how early userspace can move that to userspace.
> >But what about swsuspend?
> >
> >Are there any more kernel options taking file names? I think now would
> >be a good time to stop adding more of them :)
> 
> "console=" takes driver-supplied names which usually happen to match 
> /dev node names. For example, drivers/serial/8250.c names itself 
> "ttyS", so "console=ttyS0" will end up going to that driver, regardless 
> of the state of /dev.

These are just string matches that the different console drivers use.
They have nothing to do with an actual /dev node.

thanks,

greg k-h

Re: udev and devfs - The final word

[viro]

On Wed, Dec 31, 2003 at 05:20:18PM -0500, Rob Love wrote:
> On Wed, 2003-12-31 at 17:01, Nathan Conrad wrote:
> 
> > One thing that I'm confused about with respect to device files is how
> > kernel arguments are supposed to work. Now, we _seem_ to have a
> > mish-mash of different ways to tell the kernel which device to open as
> > a console, which device to use as a suspend device, etc.... Now, all
> > of the device names are being migrated to userland. How is the kernel
> > supposed to determine which device to use when it is told use
> > /dev/hda3 or /dev/ide/host0/something/part3 as the suspend partition?
> > The kernel no longer knows to which device this string this device is
> > connected.
> 
> Uh, Unix systems (Linux included) do not use the filename of the device
> node at all.  Those are just names for you, the user.
> 
> The kernel uses the device number to understand what device user-space
> is trying to access.  The kernel associates the device with a device
> number.  Normally that number is static, and known a priori, so we just
> create a huge /dev directory with all possible devices and their
> assigned numbers (you can see these numbers with ls -la).
> 
> But if the kernel _tells_ user-space what the device number is, for each
> device as it is created, we do not need a static /dev directory.  We can
> assemble the directory on the fly and device numbers really no longer
> matter.  This is what udev does.

I think you've missed a point here.  There are several places where kernel
deals with device identification.
	a) when normal pathname lookup results in a device node on filesystem.
That's the regular way.
	b) when we create a new device node; device number is passed to
->mknod() and new device node is created.  Also a normal codepath.
	c) when late-boot code mounts the final root.  It used to be black
magic, but these days it's done by regular syscalls.  Namely, we parse the
"device name" (most of the work is done by lookups in sysfs), do mknod(2)
and mount(2).  It's still done from the kernel mode, but it could be moved
to userland.  Should be, actually.
	d) when kernel deals with resume/suspend stuff.  Currently - black
magic.  Should be moved to early userland (same parser as for final root
name + mknod on rootfs + open() to get the device in question).
	e) in several pathological syscalls we pass device number to
identify a device.  ustat(2) and its ilk - bad API that can't die.
	f) /dev/raw passes device number to bind raw device to block device.
Bad API; we probably ought to replace it with saner one at some point.
	g) RAID setup - mix of both pathologies; should be done in userland
and interfaces are in bad need of cleanup.
	h) nfsd uses device number as a substitute for export ID if said
ID is not given explicitly.  That, BTW, is a big problem for crackpipe
dreams about random device numbers - export ID _must_ be stable across
reboots.
	i) mtdblk parses "device name" on boot; should be take to early
userland, same as RAID et.al.

	Eventually name_to_dev_t() should be gone from kernel mode
completely - all callers should be shifted to early userland.  But
that will take a lot of work - currently we have a big mess in that
area.

Re: udev and devfs - The final word

[Rob Love]

On Wed, 2003-12-31 at 17:55, viro@parcelfarce.linux.theplanet.co.uk
wrote:

> I think you've missed a point here.  There are several places where kernel
> deals with device identification.

I know all of this.  I was trying to explain how Unix VFS understands
devices (via major/minor number, not filename).  Different audience.

	Rob Love

Re: udev and devfs - The final word

[Andreas Dilger]

On Dec 31, 2003  22:55 +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> 	h) nfsd uses device number as a substitute for export ID if said
> ID is not given explicitly.  That, BTW, is a big problem for crackpipe
> dreams about random device numbers - export ID _must_ be stable across
> reboots.

We had a problem with this and Lustre, when we NFS export it.  Lustre is
already a network filesystem so we don't have a device number.  I had a
discussion with Neil Brown about this and suggested that we allow NFS to
get a _real_ stable export ID from the filesystem (e.g. superblock UUID
or similar) instead of the device number hackery which only has a vague
relationship to stable.

We implemented it for Lustre with a filesystem option FS_NFSEXP_FSID
that tells nfsd it can export such a filesystem in the absence of
FS_REQUIRES_DEV and then put our export ID into sb->s_dev (although I'd
prefer something slightly cleaner than that).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: udev and devfs - The final word

[Olaf Hering]

 On Wed, Dec 31, viro@parcelfarce.linux.theplanet.co.uk wrote:

> On Wed, Dec 31, 2003 at 05:20:18PM -0500, Rob Love wrote:
> > On Wed, 2003-12-31 at 17:01, Nathan Conrad wrote:

> > Uh, Unix systems (Linux included) do not use the filename of the device
> > node at all.  Those are just names for you, the user.
> > 
> > The kernel uses the device number to understand what device user-space
> > is trying to access.  The kernel associates the device with a device
> > number.  Normally that number is static, and known a priori, so we just
> > create a huge /dev directory with all possible devices and their
> > assigned numbers (you can see these numbers with ls -la).
> > 
> > But if the kernel _tells_ user-space what the device number is, for each
> > device as it is created, we do not need a static /dev directory.  We can
> > assemble the directory on the fly and device numbers really no longer
> > matter.  This is what udev does.
> 
> I think you've missed a point here.  There are several places where kernel
> deals with device identification.
> 	a) when normal pathname lookup results in a device node on filesystem.
> That's the regular way.
> 	b) when we create a new device node; device number is passed to
> ->mknod() and new device node is created.  Also a normal codepath.
> 	c) when late-boot code mounts the final root.  It used to be black
> magic, but these days it's done by regular syscalls.  Namely, we parse the
> "device name" (most of the work is done by lookups in sysfs), do mknod(2)
> and mount(2).  It's still done from the kernel mode, but it could be moved
> to userland.  Should be, actually.
> 	d) when kernel deals with resume/suspend stuff.  Currently - black
> magic.  Should be moved to early userland (same parser as for final root
> name + mknod on rootfs + open() to get the device in question).
> 	e) in several pathological syscalls we pass device number to
> identify a device.  ustat(2) and its ilk - bad API that can't die.
> 	f) /dev/raw passes device number to bind raw device to block device.
> Bad API; we probably ought to replace it with saner one at some point.
> 	g) RAID setup - mix of both pathologies; should be done in userland
> and interfaces are in bad need of cleanup.
> 	h) nfsd uses device number as a substitute for export ID if said
> ID is not given explicitly.  That, BTW, is a big problem for crackpipe
> dreams about random device numbers - export ID _must_ be stable across
> reboots.
> 	i) mtdblk parses "device name" on boot; should be take to early
> userland, same as RAID et.al.

This is about the /proc/self/mounts format:

Why does it contain stuff like "/dev/root" or "/dev/sda3" or
"/dev/myblockdevice"? Does anyone __really__ care about it? I doubt
that. What I have here (with 2.4) is:

olh@melon:~> cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/vg_melon/abuild /abuild ext3 rw 0 0
/dev/vg_melon/data1 /data1 ext3 rw 0 0
/dev/vg_melon/data2 /data2 ext3 rw 0 0
shmfs /dev/shm shm rw 0 0
automount(pid937) /suse autofs rw 0 0
wotan:/real-home/jplack /suse/jplack nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,tcp,nolock,addr=wotan 0 0
wotan:/real-home/olh /suse/olh nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,tcp,nolock,addr=wotan 0 0

Now, thats just fine and it was always been that way.
What if I chroot into /foo, proc is mounted on /foo/proc,
and run fsck /dev/sda3 in that chroot? 
That silly app looks for /etc/mtab (oh my...) and start the work.
Fine. Now, /dev/root is in reality /dev/sda3. Bad for me.

the whole thing would work as expected of /proc/self/mounts would have
a sane format:
olh@melon:~> cat /proc/mounts
0:0 / rootfs rw 0 0
8:3 / ext3 rw 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
58:0 /abuild ext3 rw 0 0
58:1 /data1 ext3 rw 0 0
58:2 /data2 ext3 rw 0 0
shmfs /dev/shm shm rw 0 0
automount(pid937) /suse autofs rw 0 0
wotan:/real-home/jplack /suse/jplack nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,tcp,nolock,addr=wotan 0 0
wotan:/real-home/olh /suse/olh nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,tcp,nolock,addr=wotan 0 0

Now fsck could look for /dev/sda3, realize that it is a block
device node and look for that in the kernel mount table.
If it is mounted, abort with a nice and meaningful error message.

So my question is: why was this strange format invented in the first place?
And: will 2.7 get a sane /proc/self/mounts format for block devices?

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Re: udev and devfs - The final word

[viro]

On Wed, Jan 07, 2004 at 11:15:59AM +0100, Olaf Hering wrote:
> Now, thats just fine and it was always been that way.
> What if I chroot into /foo, proc is mounted on /foo/proc,
> and run fsck /dev/sda3 in that chroot? 
> That silly app looks for /etc/mtab (oh my...) and start the work.
> Fine. Now, /dev/root is in reality /dev/sda3. Bad for me.

Huh?
 
> the whole thing would work as expected of /proc/self/mounts would have
> a sane format:
> olh@melon:~> cat /proc/mounts
> 0:0 / rootfs rw 0 0
> 8:3 / ext3 rw 0 0
> proc /proc proc rw 0 0
> devpts /dev/pts devpts rw 0 0
> 58:0 /abuild ext3 rw 0 0
> 58:1 /data1 ext3 rw 0 0
> 58:2 /data2 ext3 rw 0 0
> shmfs /dev/shm shm rw 0 0
> automount(pid937) /suse autofs rw 0 0
> wotan:/real-home/jplack /suse/jplack nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,tcp,nolock,addr=wotan 0 0
> wotan:/real-home/olh /suse/olh nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,tcp,nolock,addr=wotan 0 0

It's *NOT* a sane format.

> Now fsck could look for /dev/sda3, realize that it is a block
> device node and look for that in the kernel mount table.
> If it is mounted, abort with a nice and meaningful error message.
> 
> So my question is: why was this strange format invented in the first place?
> And: will 2.7 get a sane /proc/self/mounts format for block devices?

Yes.  It already has one.

Note that you're not only adding ad-hackery (which filesystems get that
major:minor printed and which do not?), you *STILL* hadn't solved your
problem.  Why?  Because you still won't catch e.g. ext3 on /dev/sda5 with
external journal on /dev/sda3.  And if you hack parsing ext3 lines in
/proc/mounts, there's always reiserfs, jfs, etc., etc.  _And_ there's
RAID with the same problems wrt. access to components.  Real funny
when you have raid0 on md0, have md0 mounted and try to fsck one of
components.

Scanning /etc/mtab or /proc/mounts in such situations is wrong.  If fsck
is doing that, it's broken.  The right way to fix it depends on what you
really want and whatever the hell it is, putting new and new fs-specific
code that would parse /proc/mounts lines into fsck(8) is not an answer.

Re: udev and devfs - The final word

[Olaf Hering]

 On Wed, Jan 07, viro@parcelfarce.linux.theplanet.co.uk wrote:

> On Wed, Jan 07, 2004 at 11:15:59AM +0100, Olaf Hering wrote:
> > Now, thats just fine and it was always been that way.
> > What if I chroot into /foo, proc is mounted on /foo/proc,
> > and run fsck /dev/sda3 in that chroot? 
> > That silly app looks for /etc/mtab (oh my...) and start the work.
> > Fine. Now, /dev/root is in reality /dev/sda3. Bad for me.
> 
> Huh?

For short: noone knows that /dev/sda3 is busy/used.

> Note that you're not only adding ad-hackery (which filesystems get that
> major:minor printed and which do not?), you *STILL* hadn't solved your
> problem.  Why?  Because you still won't catch e.g. ext3 on /dev/sda5 with
> external journal on /dev/sda3.  And if you hack parsing ext3 lines in
> /proc/mounts, there's always reiserfs, jfs, etc., etc.  _And_ there's
> RAID with the same problems wrt. access to components.  Real funny
> when you have raid0 on md0, have md0 mounted and try to fsck one of
> components.

That makes sense. Is there a sane way to inform userland apps that some
stuff is used (mounted, part of a volume group or raid)? Sure, the raid
or lvm specific tools will tell you...

> Scanning /etc/mtab or /proc/mounts in such situations is wrong.  If fsck
> is doing that, it's broken.  The right way to fix it depends on what you
> really want and whatever the hell it is, putting new and new fs-specific
> code that would parse /proc/mounts lines into fsck(8) is not an answer.

Ok, it was mkfs.minix and an older distro. But still, is '/dev/root' or
'/dev/fred' really correct?

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Re: udev and devfs - The final word

[viro]

On Wed, Jan 07, 2004 at 02:00:36PM +0100, Olaf Hering wrote:
 
> Ok, it was mkfs.minix and an older distro.

mkfs should simply pass O_EXCL to open().  Which is what you really want
and yes, it should work on 2.6 (not sure if it got backported on 2.4).

Re: udev and devfs - The final word

[Olaf Hering]

 On Wed, Jan 07, viro@parcelfarce.linux.theplanet.co.uk wrote:

> On Wed, Jan 07, 2004 at 02:00:36PM +0100, Olaf Hering wrote:
>  
> > Ok, it was mkfs.minix and an older distro.
> 
> mkfs should simply pass O_EXCL to open().  Which is what you really want
> and yes, it should work on 2.6 (not sure if it got backported on 2.4).

Thanks! I will play with it and see what current tools use.

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Re: udev and devfs - The final word

[Andries Brouwer]

On Wed, Dec 31, 2003 at 03:19:22PM -0500, Rob Love wrote:

> We can get to the point where we don't even need the explicit concept of
> device numbers, but just "any old unique value" to use as a cookie.  The
> kernel can pull that number from anywhere, and notify user-space via
> udev ala hotplug.

My plan has been to essentially use a hashed disk serial number
for this "any old unique value". The problem is that "any old"
is easy enough, but "unique" is more difficult.
Naming devices is very difficult, but in some important cases,
like SCSI or IDE disks, that would work and give a stable name.

The kernel must not invent consecutive numbers - that does not
lead to stable names. Setting this up correctly is nontrivial.

Re: udev and devfs - The final word

[Rob Love]

On Wed, 2003-12-31 at 19:15, Andries Brouwer wrote:

> My plan has been to essentially use a hashed disk serial number
> for this "any old unique value". The problem is that "any old"
> is easy enough, but "unique" is more difficult.
> Naming devices is very difficult, but in some important cases,
> like SCSI or IDE disks, that would work and give a stable name.

Yup.

> The kernel must not invent consecutive numbers - that does not
> lead to stable names. Setting this up correctly is nontrivial.

This is definitely an interesting problem space.

I agree wrt just inventing consecutive numbers.  If there was a nice way
to trivially generate a random and unique number from some
device-inherent information, that would be nice.

	Rob Love

Re: udev and devfs - The final word

[Rob Landley]

On Wednesday 31 December 2003 18:31, Rob Love wrote:
> On Wed, 2003-12-31 at 19:15, Andries Brouwer wrote:
> > My plan has been to essentially use a hashed disk serial number
> > for this "any old unique value". The problem is that "any old"
> > is easy enough, but "unique" is more difficult.
> > Naming devices is very difficult, but in some important cases,
> > like SCSI or IDE disks, that would work and give a stable name.
>
> Yup.
>
> > The kernel must not invent consecutive numbers - that does not
> > lead to stable names. Setting this up correctly is nontrivial.
>
> This is definitely an interesting problem space.
>
> I agree wrt just inventing consecutive numbers.  If there was a nice way
> to trivially generate a random and unique number from some
> device-inherent information, that would be nice.
>
> 	Rob Love

Fundamental problem: "Unique" depends on the other devices in the system.  You 
can't guarantee unique by looking at one device, more or less by definition.

Combine that with hotplug and you have a world of pain.  Generating a number 
from a device is just a fancy hashing function, but as soon as you have two 
devices that generate the same number independently (when in separate 
systems) and you plug them both into the same system: boom.

Now if you don't care about hotplug, it gets a little easier.  You can have a 
collission handler that does some kind of hashing thing, figuring out which 
device needs to get bumped and bumping it.  (As long as it consistently picks 
the same victim, you're okay, although that in and of itself could get 
interesting.  And if you remove the earlier device it conflicted with and 
reboot, the device could get renumbered which is evil...)

Of course the EASY way to deal with collisions is to just fail the hash thingy 
in a detectable way, and punt to some kind of udev override.  So if you yank 
a drive from system A, throw it in system B, try to re-export it NFS, and 
it's not going to work, it TELLS you.

Solve 90% of the problem space and have a human deal with the exceptions.  How 
big's the unique number being exported, anyway?  (If it's 32 bits, the 
exceptions are 1 in 4 billion.  It may never be seen in the wild...)

Rob

Re: udev and devfs - The final word

[Rob Love]

On Thu, 2004-01-01 at 07:34, Rob Landley wrote:

> Fundamental problem: "Unique" depends on the other devices in the system.  You 
> can't guarantee unique by looking at one device, more or less by definition.

Of course.

> Combine that with hotplug and you have a world of pain.  Generating a number 
> from a device is just a fancy hashing function, but as soon as you have two 
> devices that generate the same number independently (when in separate 
> systems) and you plug them both into the same system: boom.

A solution would have to deal with collisions.

> Of course the EASY way to deal with collisions is to just fail the hash thingy 
> in a detectable way, and punt to some kind of udev override.  So if you yank 
> a drive from system A, throw it in system B, try to re-export it NFS, and 
> it's not going to work, it TELLS you.

No no no.  Nothing this complicated.  No punting to udev.

> Solve 90% of the problem space and have a human deal with the exceptions.  How 
> big's the unique number being exported, anyway?  (If it's 32 bits, the 
> exceptions are 1 in 4 billion.  It may never be seen in the wild...)

Device numbers are 64-bit now.

	Rob Love

Re: udev and devfs - The final word

[Andries Brouwer]

On Thu, Jan 01, 2004 at 10:22:53AM -0500, Rob Love wrote:

> Device numbers are 64-bit now.
> 
> 	Rob Love

I am afraid I have to disappoint you. I made them 64-bit,
and I think they were 64-bit for a few months in the -mm tree,
forgot the details, but unfortunately Al went back to 32-bit again.

Re: udev and devfs - The final word

[Rob Love]

On Thu, 2004-01-01 at 10:48, Andries Brouwer wrote:

> I am afraid I have to disappoint you. I made them 64-bit,
> and I think they were 64-bit for a few months in the -mm tree,
> forgot the details, but unfortunately Al went back to 32-bit again.

You did disappoint me!  My heart is crushed and my aspirations for the
future ruined.

But you are right, dunno what I was thinking.

	Rob Love

Re: udev and devfs - The final word

[Linus Torvalds]

On Thu, 1 Jan 2004, Rob Love wrote:
>
> On Thu, 2004-01-01 at 10:48, Andries Brouwer wrote: 
> > I am afraid I have to disappoint you. I made them 64-bit,
> > and I think they were 64-bit for a few months in the -mm tree,
> > forgot the details, but unfortunately Al went back to 32-bit again.
> 
> You did disappoint me!  My heart is crushed and my aspirations for the
> future ruined.
> 
> But you are right, dunno what I was thinking.

Note that one reason I didn't much like the 64-bit versions is that not 
only are they bigger, they also encourage insanity. Ie you'd find SCSI 
people who want to try to encode device/controller/bus/target/lun info 
into the device number. 

We should resist any effort that makes the numbers "mean" something. They 
are random cookies. Not "unique identifiers", and not "addresses".

The unique identifiers you get from things like udev, using contents of
the device itself or user preferences etc. That's outside the scope of the
kernel. The addresses you get from /sys.

		Linus

Re: udev and devfs - The final word

[Andries Brouwer]

On Fri, Jan 02, 2004 at 12:42:41PM -0800, Linus Torvalds wrote:

Hi Linus - A happy 2004 !


> Note that one reason I didn't much like the 64-bit versions is that not 
> only are they bigger, they also encourage insanity. Ie you'd find SCSI 
> people who want to try to encode device/controller/bus/target/lun info 
> into the device number. 

Weak. "We don't want this power that has good uses because it also
can be used stupidly." That is not Unix-style.

> We should resist any effort that makes the numbers "mean" something. They 
> are random cookies. Not "unique identifiers", and not "addresses".

Random cookies? I prefer "arbitrary" over "random". The value plays no role
at all, but it must be unique, preferably stable across reboots.

Andries

Re: udev and devfs - The final word

[Linus Torvalds]

On Sat, 3 Jan 2004, Andries Brouwer wrote:
> 
> > Note that one reason I didn't much like the 64-bit versions is that not 
> > only are they bigger, they also encourage insanity. Ie you'd find SCSI 
> > people who want to try to encode device/controller/bus/target/lun info 
> > into the device number. 
> 
> Weak. "We don't want this power that has good uses because it also
> can be used stupidly." That is not Unix-style.

No.

That's not the argument: the argument is that the _only_ thing that 64-bit 
stuff can be used for is stupid things.

For everything else, a 32-bit dev_t is sufficient.

And the UNIX way is definitely: "do one thing, and do it well" and "small
is beautiful". It has _never_ been "overdesign everything to accomodate
stupidity".

You may have confused UNIX with Multics. Where overdesign was the rule, 
not the exception.

> > We should resist any effort that makes the numbers "mean" something. They 
> > are random cookies. Not "unique identifiers", and not "addresses".
> 
> Random cookies? I prefer "arbitrary" over "random". The value plays no role
> at all, but it must be unique, preferably stable across reboots.

Don't use "unique". It has way too many connotations of _true_ uniqieness 
in computer science.

And the operative word in "preferably stable across reboots" is
"preferably". Because it basically cannot be in the general case (it 
can't be unique for things that aren't enumerable, and clearly a lot of 
things aren't), and thus nothing must ever _assume_ it is.

And the thing is, to break those wrong assumptions (that are true in many
common cases, but are _not_ true in the rare general case), we may have to
actively do things that are "silly" on purpose. For example, for 
debugging, we start the "jiffies" counter not at zero, but at -300. That's 
patently _silly_, but it was very useful in finding the cases where the 
rare general case was not handled correctly.

Similarly, I'll probably advocate at some point (when distributions are
using udev) that we purposefully try to make device numbers _unstable_
across reboots, to find cases that do the wrong thing and have things
hardcoded. Exactly to find and fix them, so that the distribution works 
correctly even when things aren't enumerable.

(As to examples of inumerable devices, iSCSI comes to mind. As does pretty 
much anything else that is connected over IP - you can't even enumerate 
according to path or IP, since those may change too).

		Linus

Re: udev and devfs - The final word

[Andries Brouwer]

On Fri, Jan 02, 2004 at 08:46:33PM -0800, Linus Torvalds wrote:

> > Random cookies? I prefer "arbitrary" over "random". The value plays no role
> > at all, but it must be unique, preferably stable across reboots.
> 
> The operative word in "preferably stable across reboots" is
> "preferably". Because it basically cannot be in the general case,
> and thus nothing must ever _assume_ it is.

Sure. It is not "need". It is "quality of implementation".
Consider NFS.

Andries

Re: udev and devfs - The final word

[Linus Torvalds]

On Sat, 3 Jan 2004, Andries Brouwer wrote:
> 
> Sure. It is not "need". It is "quality of implementation".
> Consider NFS.

The problems occur when there are things we _cannot_ guarantee, and that
user space starts unnecessarily to depend on. And that ends up resulting
in bugs waiting to happen. Bugs that many "normal" developers may never 
hit, simply because the quality of implementation ends up being so good 
that it hides the problem cases in regular usage.

And then a high-quality implementation actually ends up being 
_detrimental_. It's hiding problems that can still happen, they just 
happen rarely enough that the bugs don't get found and fixed.

And then the painful thing of forcing "stupid", aka "bad QoI" behaviour, 
actually ends up being the better thing in the long run.

			Linus

Re: udev and devfs - The final word

[Andries Brouwer]

On Sat, Jan 03, 2004 at 02:27:47PM -0800, Linus Torvalds wrote:

> > Sure. It is not "need". It is "quality of implementation".
> > Consider NFS.

> And then a high-quality implementation actually ends up being 
> _detrimental_. It's hiding problems that can still happen, they just 
> happen rarely enough that the bugs don't get found and fixed.

Empty talk. This is not about finding and fixing bugs.
We know very precisely what properties the NFS protocol has.
Now one can have a system that works as well as possible with NFS.
And one can have a worse system.

Andries

Re: udev and devfs - The final word

[Mark Mielke]

On Sun, Jan 04, 2004 at 12:08:40AM +0100, Andries Brouwer wrote:
> On Sat, Jan 03, 2004 at 02:27:47PM -0800, Linus Torvalds wrote:
> > And then a high-quality implementation actually ends up being 
> > _detrimental_. It's hiding problems that can still happen, they just 
> > happen rarely enough that the bugs don't get found and fixed.
> Empty talk. This is not about finding and fixing bugs.
> We know very precisely what properties the NFS protocol has.
> Now one can have a system that works as well as possible with NFS.
> And one can have a worse system.

It seems to me that as long as /dev is always a local mount (tmpfs in
the case of an NFS-root installation), it doesn't really matter. Maintaining
system-specific information on a remote machine seems dirty, and something
that shouldn't be *expected* to work. You wouldn't expect /proc to work
over NFS, would you? :-)

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 and devfs - The final word

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Sat, 03 Jan 2004 20:16:26 EST, Mark Mielke said:

> It seems to me that as long as /dev is always a local mount (tmpfs in
> the case of an NFS-root installation), it doesn't really matter. Maintaining
> system-specific information on a remote machine seems dirty, and something
> that shouldn't be *expected* to work. You wouldn't expect /proc to work
> over NFS, would you? :-)

ISTR that SunOS 4.0 handled an NFS-mounted /dev and swap just fine some 15
years ago? (in fact, due to performance differences between the disks on a Sun3/
2xx server and the shoebox disk on a 3/50, you could page faster over the net
than to a local /dev/swap).

So it's more a case of "we have decided to do it differently" than "that's so nuts
that it shouldn't be expected to work"....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: udev and devfs - The final word

[Mark Mielke]

On Sat, Jan 03, 2004 at 08:54:36PM -0500, Valdis.Kletnieks@vt.edu wrote:
> ISTR that SunOS 4.0 handled an NFS-mounted /dev and swap just fine
> some 15 years ago? (in fact, due to performance differences between
> the disks on a Sun3/ 2xx server and the shoebox disk on a 3/50, you
> could page faster over the net than to a local /dev/swap).

Whether it did at some point, or whether it didn't, doesn't really matter.

It doesn't need to, and with the amount of memory that most computers come
with these days, remote access storage for tiny kernel data structures, like
that which would be required for tmpfs /dev that is only populated with the
devices that actually exist, just isn't worth it.

> So it's more a case of "we have decided to do it differently" than
> "that's so nuts that it shouldn't be expected to work"....

I was saying "why do you think this is a good model?" not "I can't imagine
why you would do it..." :-) Sorry it didn't come across as I intended.

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 and devfs - The final word

[Linus Torvalds]

On Sun, 4 Jan 2004, Andries Brouwer wrote:
> 
> Empty talk. This is not about finding and fixing bugs.
> We know very precisely what properties the NFS protocol has.
> Now one can have a system that works as well as possible with NFS.
> And one can have a worse system.

Oh, things can be _much_ worse than /dev over NFS. 

You don't seem to realize what I men with "not enumerable".

With NFS, you could have some strange per-mount device number mapping etc, 
and it wouldn't need to be all that complicated.

But if you start considering network-attached storage (as in "disks over
IP", not as in "samba"), the problem is that you fundamentally cannot
enumerate the things on a kernel level. EVER. There is no way to do
automatic discovery, because the bus fundamentally isn't enumerable. It
isn't even _repeatable_, ie if you do broadcast "tell me what disks
exists", the results won't be ordered some way.

In other words, the device numbers that eventually get attached to these 
disks (however the discovery ends up working - with the sysadmin 
explicitly mentioning them, or with some kind of broadcast protocol) 
simply WILL NOT NECESSARILY be the same across reboots. 

And there just _isn't_ any way to make them the same or to "describe" the 
storage in any integer of any finite length. It has nothing to do with 
32-bit vs 64-bit vs 1024-bit.

Once you accept that fact, you should accept the fact that device numbers 
not only have no meaning, they literally have no permanence across reboots 
either.

Yes, the common case is permanent. What I'm saying is that the common case 
_cannot_ be the generic case. 

		Linus

Re: udev and devfs - The final word

[Andries Brouwer]

On Sat, Jan 03, 2004 at 06:09:47PM -0800, Linus Torvalds wrote:
> On Sun, 4 Jan 2004, Andries Brouwer wrote:

> > Empty talk. This is not about finding and fixing bugs.
> > We know very precisely what properties the NFS protocol has.
> > Now one can have a system that works as well as possible with NFS.
> > And one can have a worse system.
> 
> Oh, things can be _much_ worse than /dev over NFS.

Yes, but why do you start saying that?

Our topic is the statement that it is good to have device numbers
stable across a reboot. Not absolutely necessary, but good.

For example, given an NFS mount, if the server reboots and
suddenly the client sees different stat data, that would be
less than optimal. A low quality NFS implementation.

You write long stories - but it really is desirable to have
stable device numbers.

> You don't seem to realize what I mean with "not enumerable".

One of your side avenues is the matter of enumeration.
I don't see why that would be relevant. One identifies
things by their UUID. Order is never important.

> And there just _isn't_ any way to make them the same or to "describe" the 
> storage in any integer of any finite length. It has nothing to do with 
> 32-bit vs 64-bit vs 1024-bit.

A UUID usually takes 128 bits.

Andries

Re: udev and devfs - The final word

[Linus Torvalds]

On Sun, 4 Jan 2004, Andries Brouwer wrote:
> 
> You write long stories - but it really is desirable to have
> stable device numbers.

And I write the long stories because you do not seem to _get_ the point.

The point is that we will most likely ON PURPOSE break those stable device 
numbers, for debugging reasons. Because it is _not_ desirable to have 
people _believe_ that they can depend on stable device numbers.

> I don't see why that would be relevant. One identifies
> things by their UUID. Order is never important.

And this is exactly how it should be. However, it requires that user code 
actually does the right thing.

And to _verify_ that user code properly identifies devices by other things 
than device numbers, we should during 2.7.x explicitly _break_ all 
dependencies on stable device numbers.

And UUID's are _not_ "device numbers". They fundamentally _cannot_ be 
that, because the kernel just doesn't have any information on how to 
generate a unique identifier that is actually stable.

The kernel doesn't know what it can depend on - should it look at the UUID
in the boot sector of the disk, or should it look up the UUID using IP
number reverse lookup, or what? 

The only thing that can generate a UUID is literally user mode. Which is 
_exactly_ why things like udev exists.

So device numbers are _not_ UUID's. Device numbers are needed before the 
UUID's have been identified. 

And that has been my point all along: device numbers do not have any
meaning. They are neither unique nor stable across reboots. They have no
information AT ALL associated with them. Anybody who thinks that they are
is fundamentally _wrong_ about it.

I agree that for a stable kernel we should then go back to "best effort" 
mode, where for simple politeness reasons we should try to keep device 
numbers as stable as we can. 

		Linus

Pentium 4 HT SMP

[Ananda Bhattacharya]

Hi, 
	I was wondering if one compiles a kernel for a 
Pentium 4 which has HyperThreading will we need to recompile 
SMP support for a single physical CPU or will one need to 
have SMP enabled to take advantag of hyperthreading.

thanks
	-A 

Re: Pentium 4 HT SMP

[Martin J. Bligh]

> 	I was wondering if one compiles a kernel for a 
> Pentium 4 which has HyperThreading will we need to recompile 
> SMP support for a single physical CPU or will one need to 
> have SMP enabled to take advantag of hyperthreading.

You need SMP.

M.

Re: udev and devfs - The final word

[Andries Brouwer]

On Sat, Jan 03, 2004 at 07:04:17PM -0800, Linus Torvalds wrote:

> I agree that for a stable kernel we should then go back to "best effort" 
> mode, where for simple politeness reasons we should try to keep device 
> numbers as stable as we can.

Good - you understand now.
So, the right setup - you call it politeness, I call it quality
of implementation - is to have both stable names and stable numbers,
in as many cases as possible.

Concerning the names, we are in reasonable shape. We have nameif
that binds a stable name to a MAC address. Much beter than eth2.
Also udev is a good step in the right direction - it gives
stable names under certain circumstances.

(And since udev can use the kernel device number, it can give stable
names under more circumstances when the kernel device number is
more often stable.)

Concerning the numbers, numbers based on enumeration are less than
satisfactory - they must be the last fallback when nothing else
can be found. And the ordering then is the ordering in time.

Almost always something better can be found. It is the drivers' job
to invent the device number. For the important special case of
SCSI or IDE disk, the disk serial number can be used.

Our helper function takes a string and an integer and a range, and
produces a device number in the given range, distinct from already
existing numbers. If you prefer random device numbers you make this
function ignore the string argument. I prefer stable device numbers
so would do an md5sum-like thing.

And that brings us back to the start of this thread:
Life is simpler when there is more room.
So it is a pity that we chose for less room.

Andries

Re: udev and devfs - The final word

[Linus Torvalds]

On Sun, 4 Jan 2004, Andries Brouwer wrote:
>
> On Sat, Jan 03, 2004 at 07:04:17PM -0800, Linus Torvalds wrote:
> > 
> > I agree that for a stable kernel we should then go back to "best effort" 
> > mode, where for simple politeness reasons we should try to keep device 
> > numbers as stable as we can.
> 
> Good - you understand now.

Oh, _I_ always understood. You were the one that was arguing for stable
numbers as somehow important. I'm just telling you that they aren't
stable, and that a user application that depends on their stability or
their uniqieness is BROKEN.

> So, the right setup - you call it politeness, I call it quality
> of implementation - is to have both stable names and stable numbers,
> in as many cases as possible.

And I still disagree. You seem to think that this is an "absolute 
goodness", and call it a quality issue.

While I personally strongly believe that it is a bug in user space to
care, and that it is not a quality issue at all, but rather a "allow buggy
and/or nonconverted user space to work".

In other words, it's not about "quality", as much as about compatibility 
with applications that are old and/or braindead. Big difference.

		Linus

Re: udev and devfs - The final word

[Andries Brouwer]

On Sun, Jan 04, 2004 at 01:05:20PM -0800, Linus Torvalds wrote:

> Oh, _I_ always understood. You were the one that was arguing for
> stable numbers as somehow important.

Indeed. I said "preferably stable across reboots".

> I'm just telling you that they aren't stable, and that a
> user application that depends on their stability or
> their uniqueness is BROKEN.

Surprise! Are you leaving POSIX? Or ditching NFS?
Or demanding that NFS servers must never reboot?

A common Unix idiom is testing for the identity
of two files by comparing st_ino and st_dev.
A broken idiom?

No idea what part of our Unix heritage you now have decided to call broken.

Andries

Re: udev and devfs - The final word

[viro]

On Sun, Jan 04, 2004 at 11:01:04PM +0100, Andries Brouwer wrote:
> A common Unix idiom is testing for the identity
> of two files by comparing st_ino and st_dev.
> A broken idiom?

	No, just your usual highly selective reading.  First of all, that
idiom relies only on different ->s_dev *among* *currently* *mounted*
*filesystems*.  In part that has anything to do with devices, it means
only one thing:

	Any two different block devices that are both currently opened by
	the kernel and are both alive must have different device numbers.

Note the "are alive" part - we can even allow reuse of device numbers
as long as we make sure that stat() will fail on filesystems mounted
from dead ones.

Now, care to explain how preserving aforementioned common Unix idiom
is related to your expostulations?

Re: udev and devfs - The final word

[Mark Mielke]

On Sun, Jan 04, 2004 at 10:37:10PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Sun, Jan 04, 2004 at 11:01:04PM +0100, Andries Brouwer wrote:
> > A common Unix idiom is testing for the identity
> > of two files by comparing st_ino and st_dev.
> > A broken idiom?
> 	No, just your usual highly selective reading.  First of all, that
> idiom relies only on different ->s_dev *among* *currently* *mounted*
> *filesystems*.
> ...
> Now, care to explain how preserving aforementioned common Unix idiom
> is related to your expostulations?

I think he is defending bad design practices by pointing out common
bad design practices, and asking why these bad practices shouldn't be
allowed to continue, given that they are so common... :-)

Are there any real programs that assume st_dev/st_ino values are constant
across mount/unmount/mount? If so, Linus is saying we should break these
programs, so that the authors can become aware of the problem, rather than
leaving the problem as a subtle corner case.

I see no reason at all to keep these programs running. They are incorrect,
and that is that.

If and when this comes up in 2.7 development, I would like to see an
option of the sort: 1) Try to maintain major:minor numbers across
reboots (even at the expense of complexity and efficiency), 2) Try to
maintain a subset of the major:minor numbers across reboots
(compromise) 3) Provide the most efficient implementation, making no
guarantees regarding the numbering scheme, unless using a numbering
scheme turns out to be more efficient. Deprecate 1), and let 2) and 3)
evolve until we see who the victor is... :-) As long as the interface
that maps device to number is abstracted, the above should be pluggable.

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 and devfs - The final word

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Sun, 04 Jan 2004 20:02:36 EST, Mark Mielke said:

> If and when this comes up in 2.7 development, I would like to see an
> option of the sort: 1) Try to maintain major:minor numbers across
> reboots (even at the expense of complexity and efficiency), 2) Try to
> maintain a subset of the major:minor numbers across reboots
> (compromise) 3) Provide the most efficient implementation, making no
> guarantees regarding the numbering scheme, unless using a numbering
> scheme turns out to be more efficient. Deprecate 1), and let 2) and 3)
> evolve until we see who the victor is... :-) As long as the interface
> that maps device to number is abstracted, the above should be pluggable.

I'd recommend (at least during 2.7) some code in the allocator:

	if (LINUX_VERSION_CODE % 3) {
		major ^= get_random_bytes(4);
		minor ^= get_random_bytes(4);
	}

Just to keep everybody honest. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: udev and devfs - The final word

[Andries Brouwer]

On Sun, Jan 04, 2004 at 10:37:10PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:

Hi Al - a happy 2004 to you too!

> Now, care to explain how preserving aforementioned common Unix idiom
> is related to your expostulations?

Hmm. You sound like you agree that random device numbers and NFS
are a bad combination, but don't see why my example might be
relevant.

There is a great variation here in what various servers and clients do,
but roughly speaking filehandles tend to contain a fsid, and this fsid
often (no fsid= given) involves (major,minor,ino). When device numbers
vary randomly, the fsid may vary randomly. Various bad things may happen:
maybe all file handles go stale (or, worse, refer to something else),
or maybe device numbers on the client vary randomly.

Andries

Re: udev and devfs - The final word

[viro]

On Mon, Jan 05, 2004 at 03:29:01AM +0100, Andries Brouwer wrote:
> On Sun, Jan 04, 2004 at 10:37:10PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> 
> Hi Al - a happy 2004 to you too!
> 
> > Now, care to explain how preserving aforementioned common Unix idiom
> > is related to your expostulations?
> 
> Hmm. You sound like you agree that random device numbers and NFS
> are a bad combination, but don't see why my example might be
> relevant.

No.  I don't see what the fuck does it have to POSIX compliance, ability
to determine whether two files are identical by st_ino/st_dev and common
UNIX idioms.
 
> There is a great variation here in what various servers and clients do,
> but roughly speaking filehandles tend to contain a fsid, and this fsid
> often (no fsid= given) involves (major,minor,ino).

Now, _that_ is true.  And yes, I agree that setups with unstable device
numbers do need explicit actions on part of admin.  In particular, editing
/etc/exports to add fsid= in each relevant entry.

Which means that *in* *setups* *where* *numbers* *are* *currently* *stable*
we should not make them random without admin's knowledge.  And /etc/exports
is not the only problem - RAID, journaling filesystems with device number of
log stored on-disk, etc.

*However*, if we are talking about new classes of devices, all bets are off
and proper fix is to stop using unsuitable interfaces for those devices.
For exports it means "use explicit fsid".  For RAID we both agreed, IIRC,
that raidtools will need to switch to saner API, etc.

Re: udev and devfs - The final word

[Helge Hafting]

On Sun, Jan 04, 2004 at 11:01:04PM +0100, Andries Brouwer wrote:
> On Sun, Jan 04, 2004 at 01:05:20PM -0800, Linus Torvalds wrote:
> 
> > Oh, _I_ always understood. You were the one that was arguing for
> > stable numbers as somehow important.
> 
> Indeed. I said "preferably stable across reboots".
> 
> > I'm just telling you that they aren't stable, and that a
> > user application that depends on their stability or
> > their uniqueness is BROKEN.
> 
> Surprise! Are you leaving POSIX? Or ditching NFS?
> Or demanding that NFS servers must never reboot?
> 
> A common Unix idiom is testing for the identity
> of two files by comparing st_ino and st_dev.
> A broken idiom?
> 
> No idea what part of our Unix heritage you now have decided to call broken.
> 

You worry about /dev over nfs, with the server booting in the middle of
such a comparison?  This can work even with randomized device numbers,
just don't let that nfs server populate the exported /dev itself.

Let the client(s) run udev, and have one /dev for each on persistent 
storage.  If the nfs server reboots it simply keeps serving /dev's
in whatever shape the clients set them up with.

Helge Hafting

Re: udev and devfs - The final word

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

On Sun, 04 Jan 2004 23:01:04 +0100, Andries Brouwer said:

> A common Unix idiom is testing for the identity
> of two files by comparing st_ino and st_dev.
> A broken idiom?

Comparing two of these obtained at the same time is *usually* a good
test, although racy even on current systems. (Consider the case of an
unlink()/creat() pair between the two stat() calls - there's been more than
one race condition resulting in a security hole based on THIS one).  It's
only safe if you actually have an open reference to both files before you
fstat() either one.  And yes, it has to be fstat(), as you can't guarantee
that the file referenced by path in stat() is the one you did an open() on.

Comparing the st_ino/st_dev for a file to day with one from last Friday has
NEVER been a good idea.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: udev and devfs - The final word

[Jeremy Maitin-Shepard]

Valdis.Kletnieks@vt.edu writes:

> On Sun, 04 Jan 2004 23:01:04 +0100, Andries Brouwer said:
>> A common Unix idiom is testing for the identity
>> of two files by comparing st_ino and st_dev.
>> A broken idiom?

> Comparing two of these obtained at the same time is *usually* a good
> test, although racy even on current systems. (Consider the case of an
> unlink()/creat() pair between the two stat() calls - there's been more than
> one race condition resulting in a security hole based on THIS one).  It's
> only safe if you actually have an open reference to both files before you
> fstat() either one.  And yes, it has to be fstat(), as you can't guarantee
> that the file referenced by path in stat() is the one you did an
> open() on.

Unfortunately, programs such as tar depend on inode numbers of distinct
files being distinct even when the file is not open over a period of
several minutes/seconds.  This is needed to avoid dumping hard links
more than once.  Furthermore, there is no efficient way to write
programs such as tar without depending on this capability.  Thus, if
st_ino cannot be used reliably for this purpose, it would be useful for
there to be a system call for retrieving a true
unique-within-the-filesystem identifier for the file.

-- 
Jeremy Maitin-Shepard

st_dev:st_ino (was: Re: udev and devfs - The final word)

[Mark Mielke]

On Sun, Jan 04, 2004 at 08:43:27PM -0500, Jeremy Maitin-Shepard wrote:
> Unfortunately, programs such as tar depend on inode numbers of distinct
> files being distinct even when the file is not open over a period of
> several minutes/seconds.  This is needed to avoid dumping hard links
> more than once.  Furthermore, there is no efficient way to write
> programs such as tar without depending on this capability.  Thus, if
> st_ino cannot be used reliably for this purpose, it would be useful for
> there to be a system call for retrieving a true
> unique-within-the-filesystem identifier for the file.

We already have that: st_nlink

I think you mean a system call that would allow you to be certain that
two file descriptors refer to the same file. Then, any files with
st_nlink >= 2 would have to use the system call to match them up.

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: st_dev:st_ino

[Jeremy Maitin-Shepard]

Mark Mielke <mark@mark.mielke.cc> writes:

> On Sun, Jan 04, 2004 at 08:43:27PM -0500, Jeremy Maitin-Shepard wrote:
>> Unfortunately, programs such as tar depend on inode numbers of distinct
>> files being distinct even when the file is not open over a period of
>> several minutes/seconds.  This is needed to avoid dumping hard links
>> more than once.  Furthermore, there is no efficient way to write
>> programs such as tar without depending on this capability.  Thus, if
>> st_ino cannot be used reliably for this purpose, it would be useful for
>> there to be a system call for retrieving a true
>> unique-within-the-filesystem identifier for the file.

> We already have that: st_nlink

> I think you mean a system call that would allow you to be certain that
> two file descriptors refer to the same file. Then, any files with
> st_nlink >= 2 would have to use the system call to match them up.

In order to efficiently implement tar, it is necessary to store the
inode numbers for files with a link count greater than 1 in a hash
table.  It would not be practical to keep open all of these files in
order to ensure that the inode numbers remain valid.  Thus, a different
unique identifier is needed, which is unique even for files that are not
open.

-- 
Jeremy Maitin-Shepard

Re: st_dev:st_ino

[viro]

On Sun, Jan 04, 2004 at 09:02:02PM -0500, Jeremy Maitin-Shepard wrote:
 
> In order to efficiently implement tar, it is necessary to store the
> inode numbers for files with a link count greater than 1 in a hash
> table.  It would not be practical to keep open all of these files in
> order to ensure that the inode numbers remain valid.  Thus, a different
> unique identifier is needed, which is unique even for files that are not
> open.

Files that are not open could've been removed and replaced with something
completely different since your stat(2).

Re: udev and devfs - The final word

[viro]

On Sun, Jan 04, 2004 at 08:43:27PM -0500, Jeremy Maitin-Shepard wrote:

> Unfortunately, programs such as tar depend on inode numbers of distinct
> files being distinct even when the file is not open over a period of
> several minutes/seconds.  This is needed to avoid dumping hard links
> more than once.  Furthermore, there is no efficient way to write
> programs such as tar without depending on this capability.  Thus, if
> st_ino cannot be used reliably for this purpose, it would be useful for
> there to be a system call for retrieving a true
> unique-within-the-filesystem identifier for the file.

No such thing.  It's not the matter of having a syscall to extract such
identifier - it's that on a lot of filesystems (including many common Unix
ones) there's nothing that would qualify.

Note that tar et.al. do not behave well if used on actively modified directory
tree and ->st_ino reuse is the least of the problems in that area.

Re: udev and devfs - The final word

[Jeremy Maitin-Shepard]

viro@parcelfarce.linux.theplanet.co.uk writes:

> On Sun, Jan 04, 2004 at 08:43:27PM -0500, Jeremy Maitin-Shepard wrote:
>> Unfortunately, programs such as tar depend on inode numbers of distinct
>> files being distinct even when the file is not open over a period of
>> several minutes/seconds.  This is needed to avoid dumping hard links
>> more than once.  Furthermore, there is no efficient way to write
>> programs such as tar without depending on this capability.  Thus, if
>> st_ino cannot be used reliably for this purpose, it would be useful for
>> there to be a system call for retrieving a true
>> unique-within-the-filesystem identifier for the file.

> No such thing.  It's not the matter of having a syscall to extract such
> identifier - it's that on a lot of filesystems (including many common Unix
> ones) there's nothing that would qualify.

Even if the files in question aren't being modified, created, deleted,
etc.?  Even if nothing on the filesystem is being modified, created,
deleted, etc.?

> [snip]

-- 
Jeremy Maitin-Shepard

Re: udev and devfs - The final word

[Linus Torvalds]

On Sun, 4 Jan 2004, Andries Brouwer wrote:
> 
> Surprise! Are you leaving POSIX? Or ditching NFS?
> Or demanding that NFS servers must never reboot?

Ok, Andries, time for you to take a deep breath, and calm down. Because 
your arguments are getting ridiculous in the extreme.

A NFS server is sure as hell not going to export _its_ dynamic /dev to its 
clients. That would be not just stupid, but crazy. Next you tell me that 
you were using devfs and exporting that over NFS. 

A NFS server is going to export something _totally_ different than its own 
/dev directory - it needs to be _client_-specific anyway. That's true with 
stable numbers too, btw - ever tried to mount a Solaris /dev on a Linux 
client? No workee.

> A common Unix idiom is testing for the identity
> of two files by comparing st_ino and st_dev.
> A broken idiom?

No. It still works. Even if the device numbers change across reboots.

Why? Becuase that _program_ sure as hell isn't running across a reboot.

And again, this is not something we haven't seen before. Have you ever 
looked at the "st_dev" values? Try once - look at what it returns for a 
NFS-mounted filesystem. Ponder. Notice how it already is NOT stable across 
reboots.

In other words, the stuff you're complaining about is all stuff that 
nobody has _ever_ been able to rely on, and that has nothign to do with 
udev or anythign else. It all just shows how 100% right I am for saying 
that you cannot rely on stable numbers.

So I repeat: calm down, and think it through.

		Linus

Re: udev and devfs - The final word

[David Lang]

Linus, what Andries is saying is that if you export a directory (say
/home) the process of exporting it somehow uses the /dev device number so
if the server reboots and gets a different device number for the partition
that /home is on the clients won't see it as the same export, breaking the
NFS requirement that a server can be rebooted.

I don't agree with him becouse if the NFS server does include /dev info in
what it shows to the outside world it's already broken.

David Lang


 On Sun, 4 Jan 2004, Linus Torvalds wrote:

> Date: Sun, 4 Jan 2004 18:52:56 -0800 (PST)
> From: Linus Torvalds <torvalds@osdl.org>
> To: Andries Brouwer <aebr@win.tue.nl>
> Cc: Rob Love <rml@ximian.com>, rob@landley.net,
>      Pascal Schmidt <der.eremit@email.de>, linux-kernel@vger.kernel.org,
>      Greg KH <greg@kroah.com>
> Subject: Re: udev and devfs - The final word
>
>
>
> On Sun, 4 Jan 2004, Andries Brouwer wrote:
> >
> > Surprise! Are you leaving POSIX? Or ditching NFS?
> > Or demanding that NFS servers must never reboot?
>
> Ok, Andries, time for you to take a deep breath, and calm down. Because
> your arguments are getting ridiculous in the extreme.
>
> A NFS server is sure as hell not going to export _its_ dynamic /dev to its
> clients. That would be not just stupid, but crazy. Next you tell me that
> you were using devfs and exporting that over NFS.
>
> A NFS server is going to export something _totally_ different than its own
> /dev directory - it needs to be _client_-specific anyway. That's true with
> stable numbers too, btw - ever tried to mount a Solaris /dev on a Linux
> client? No workee.
>
> > A common Unix idiom is testing for the identity
> > of two files by comparing st_ino and st_dev.
> > A broken idiom?
>
> No. It still works. Even if the device numbers change across reboots.
>
> Why? Becuase that _program_ sure as hell isn't running across a reboot.
>
> And again, this is not something we haven't seen before. Have you ever
> looked at the "st_dev" values? Try once - look at what it returns for a
> NFS-mounted filesystem. Ponder. Notice how it already is NOT stable across
> reboots.
>
> In other words, the stuff you're complaining about is all stuff that
> nobody has _ever_ been able to rely on, and that has nothign to do with
> udev or anythign else. It all just shows how 100% right I am for saying
> that you cannot rely on stable numbers.
>
> So I repeat: calm down, and think it through.
>
> 		Linus
> -
> 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: udev and devfs - The final word

[Rob Landley]

On Sunday 04 January 2004 21:06, David Lang wrote:
> Linus, what Andries is saying is that if you export a directory (say
> /home) the process of exporting it somehow uses the /dev device number so
> if the server reboots and gets a different device number for the partition
> that /home is on the clients won't see it as the same export, breaking the
> NFS requirement that a server can be rebooted.

NFS always struck me as a peverse design.  "The fileserver must be stateless 
with regard to clients, even though maintainging state is what a filesystem 
DOES, and the point of the thing is to export a filesystem."  Okay...  (If it 
was exporting read-only filesystems with no locking of any kind, maybe they'd 
have a point, but come on guys...)

So here's an example of where the fileserver _does_ expect to maintain 
non-file state across reboots.  "Ooh, the device node we're exporting is part 
of the ID, gee, we missed one!"

So why, exactly, can the NFS server not maintain whatever extra state it needs 
to remember between reboots in a filesystem?  (Not even necessarily the one 
it's exporting, just some rc file something under /var.)  The device node it 
was exporting USED to be in the filesystem, you know, ala mknod.  Now that 
the kernel's not keeping that stable, have the #*%(&# server generate a 
number and make a note of it somewhere.  (Is requiring an NFS server to have 
access to persistent storage too much to ask?)

Personally, I could never figure out why Samba servers are in userspace but 
NFS servers seem to want to live in the kernel.  I can almost secure a samba 
server for access to the outside world, but a NFS system that isn't behind a 
firewall automatically says to me "this machine has already been compromised 
eight ways from sunday within five minutes of being exposed to the internet".  
Call me paranoid...

Rob

Re: udev and devfs - The final word

[Trond Myklebust]

På su , 04/01/2004 klokka 22:48, skreiv Rob Landley:

> NFS always struck me as a peverse design.  "The fileserver must be stateless 
> with regard to clients, even though maintainging state is what a filesystem 
> DOES, and the point of the thing is to export a filesystem."  Okay...  (If it 
> was exporting read-only filesystems with no locking of any kind, maybe they'd 
> have a point, but come on guys...)

Sigh... What has that got to do with anything?

Read the RFCs: NFS *was* entirely stateless until v4 was drafted.
Locking was never part of the NFS protocol, but was an external addition
that was documented by the Open Group. So, yes, there is a history and a
reason behind all the talk of statelessness.

As for the current thread about remembering device numbers: as far as
NFS is concerned, that is entirely an implementation issue. There is no
need for any extra NFS protocol support for this sort of crap.

> So why, exactly, can the NFS server not maintain whatever extra state it needs 
> to remember between reboots in a filesystem?  (Not even necessarily the one 
> it's exporting, just some rc file something under /var.)  The device node it 
> was exporting USED to be in the filesystem, you know, ala mknod.  Now that 
> the kernel's not keeping that stable, have the #*%(&# server generate a 
> number and make a note of it somewhere.  (Is requiring an NFS server to have 
> access to persistent storage too much to ask?)

It could be done (and probably entirely in userspace). I assume you are
volunteering to do the work?

> Personally, I could never figure out why Samba servers are in userspace but 
> NFS servers seem to want to live in the kernel.  I can almost secure a samba 
> server for access to the outside world, but a NFS system that isn't behind a 
> firewall automatically says to me "this machine has already been compromised 
> eight ways from sunday within five minutes of being exposed to the internet".  
> Call me paranoid...

Sun was doing Kerberos for NFS years before the Samba project was
started.

Security has bugger all to do with kernel or userland and everything to
do with the short-sighted "munitions" policies of certain governments at
the time around when the Sun RPC protocol was being drafted. The same
policies were still around to dictate our implementation much later when
we were doing RPC for Linux. Now the laws have changed, and so we've
finally been able to add strong authentication in 2.6.x.

Cheers,
  Trond

[offtopic] Re: udev and devfs - The final word

[Rob Landley]

On Sunday 04 January 2004 22:52, Trond Myklebust wrote:
> På su , 04/01/2004 klokka 22:48, skreiv Rob Landley:
> > NFS always struck me as a peverse design.  "The fileserver must be
> > stateless with regard to clients, even though maintainging state is what
> > a filesystem DOES, and the point of the thing is to export a filesystem."
> >  Okay...  (If it was exporting read-only filesystems with no locking of
> > any kind, maybe they'd have a point, but come on guys...)
>
> Sigh... What has that got to do with anything?
>
> Read the RFCs: NFS *was* entirely stateless until v4 was drafted.
> Locking was never part of the NFS protocol, but was an external addition
> that was documented by the Open Group. So, yes, there is a history and a
> reason behind all the talk of statelessness.

I vaguely remember being pretty well up to speed on V2 (circa... 1995?)  The 
last one I even glanced at was V3, but I never had to support it.  I haven't 
even looked at V4.  For exporting /home directories, everybody I deal with 
seems to want samba servers these days instead for some reason.  (Couple of 
net boot systems that care more about permissions than that, but ram's so 
cheap that it's easier to just "ssh user@bootserver -i key "cat root_img.tgz" 
| tar xz" into a ramfs or shmfs or some such.  (Heck, the last system I set 
up like that mounted a zisofs image and ran from that...)

I'm sure it's still useful.  I just haven't wanted to even attempt to secure 
it.  For home directories, samba is doing a simple tcp/ip connection per 
session, reestablishing it automatically if it breaks (same server reboot 
question).  Since _both_ protocols seem to suck pretty badly under the hood, 
it's been a question of choosing the lesser of two evils.  It seems that more 
people actually USE samba, so...

> > So why, exactly, can the NFS server not maintain whatever extra state it
> > needs to remember between reboots in a filesystem?  (Not even necessarily
> > the one it's exporting, just some rc file something under /var.)  The
> > device node it was exporting USED to be in the filesystem, you know, ala
> > mknod.  Now that the kernel's not keeping that stable, have the #*%(&#
> > server generate a number and make a note of it somewhere.  (Is requiring
> > an NFS server to have access to persistent storage too much to ask?)
>
> It could be done (and probably entirely in userspace). I assume you are
> volunteering to do the work?

I don't like nfs, I haven't bothered to actually use it for anything since 
1999, so no.

> > Personally, I could never figure out why Samba servers are in userspace
> > but NFS servers seem to want to live in the kernel.  I can almost secure
> > a samba server for access to the outside world, but a NFS system that
> > isn't behind a firewall automatically says to me "this machine has
> > already been compromised eight ways from sunday within five minutes of
> > being exposed to the internet". Call me paranoid...
>
> Sun was doing Kerberos for NFS years before the Samba project was
> started.
>
> Security has bugger all to do with kernel or userland and everything to
> do with the short-sighted "munitions" policies of certain governments at
> the time around when the Sun RPC protocol was being drafted. The same

I can transparently tunnel any tcp/ip session through ssh with some iptables 
rules and a dozen line python script.  (Great fun for rolling your own vpn.)  
Mixing UDP and encryption is just plain a bad idea: no level at which it 
makes sense to store persistent connection state in a "fire and forget" 
packet protocol...)

I.E. this also works with samba, but didn't with (old) NFS.

> policies were still around to dictate our implementation much later when
> we were doing RPC for Linux. Now the laws have changed, and so we've
> finally been able to add strong authentication in 2.6.x.

Can you recommend a good link to the history of NFS?  Computer history's a 
hobby of mine.  (I've got snippets on this topic, but not any kind of unified 
story of NFS...)

http://www.landley.net/history/mirror/index.html
http://www.landley.net/history/scans/index.html

> Cheers,
>   Trond

Rob

Re: [offtopic] Re: udev and devfs - The final word

[Trond Myklebust]

På må , 05/01/2004 klokka 02:03, skreiv Rob Landley:

> I'm sure it's still useful.  I just haven't wanted to even attempt to secure 
> it.  For home directories, samba is doing a simple tcp/ip connection per 
> session, reestablishing it automatically if it breaks (same server reboot 
> question).

...and so does NFS.

>   Since _both_ protocols seem to suck pretty badly under the hood, 
> it's been a question of choosing the lesser of two evils.  It seems that more 
> people actually USE samba, so...

...and 95% of all desktop machines are Windows based. So what's new?

> > It could be done (and probably entirely in userspace). I assume you are
> > volunteering to do the work?
> 
> I don't like nfs, I haven't bothered to actually use it for anything since 
> 1999, so no.

Then you're unlikely to get the feature until someone else finds it
worth their while to implement it.

> I can transparently tunnel any tcp/ip session through ssh with some iptables 
> rules and a dozen line python script.  (Great fun for rolling your own vpn.)  
> Mixing UDP and encryption is just plain a bad idea: no level at which it 
> makes sense to store persistent connection state in a "fire and forget" 
> packet protocol...)

So do the same thing with NFS now that we've finally gotten RPC over TCP
fully supported under Linux too: everybody else has had it for years.

In 2.6.x, we've also added native RPCSEC_GSS support for kerberos-based
authentication. Packet integrity checking and full privacy are in the
pipeline, as are other security mechanisms.

> Can you recommend a good link to the history of NFS?  Computer history's a 
> hobby of mine.  (I've got snippets on this topic, but not any kind of unified 
> story of NFS...)

Dunno if anybody has ever written a proper history of NFS, but I can ask
around. Here are a few sources I found on the fly though. They all tend
to relate to the history of the protocol, and not much about
implementation history (shame that).

NFSv2 transition to NFSv3
        http://www.netapp.com/tech_library/evolution.html
        RFC1813

transition to NFSv4 
        http://www.ietf.org/html.charters/nfsv4-charter.html
        (in particular see http://www.ietf.org/rfc/rfc2624.txt which
        runs through the earlier design considerations)
        RFC3530 (the final version of the protocol)

I'd also recommend nosing around the Connectathon site on
http://www.connectathon.org/
That contains a record of talks going back to 95 (not really that long -
I know) and so should help out with the more recent history.

...of course if you google around, you'll also find loads of Powerpoint
presentations etc...

Cheers,
  Trond

Re: udev and devfs - The final word

[Mark Mielke]

On Sun, Jan 04, 2004 at 09:48:24PM -0600, Rob Landley wrote:
> On Sunday 04 January 2004 21:06, David Lang wrote:
> > Linus, what Andries is saying is that if you export a directory (say
> > /home) the process of exporting it somehow uses the /dev device number so
> > if the server reboots and gets a different device number for the partition
> > that /home is on the clients won't see it as the same export, breaking the
> > NFS requirement that a server can be rebooted.
> NFS always struck me as a peverse design.  "The fileserver must be
> stateless with regard to clients, even though maintainging state is
> what a filesystem DOES, and the point of the thing is to export a
> filesystem."  Okay...  (If it was exporting read-only filesystems
> with no locking of any kind, maybe they'd have a point, but come on
> guys...)

Statelessness translated to capacity back in the day when maintaining state
for hundreds or thousands of machines was expensive...

I don't buy NFS as an excuse, though. I refuse to believe that a
shared /dev is necessary or desirable for *any* environment. /dev/pts
is one example of where everybody seems to have already agreed on
this.

With udev, or with devfs, a shared /dev becomes unnecessary. /dev will
no longer need to be 7000+ entries. It could be a few hundred or less
for common configurations, and 0% persistence/remote storage for
tmpfs-udev or devfs.

There are a few cases that we might be forced to maintain regular
numbers: mkfifo() creates a named pipe, and bind() creates a named
socket. These might be accessed between reboots over NFS, or local
mounts by many existing programs. I think these must be guaranteed to
keep the same major:minor numbers across reboots (preferably, even
across kernel releases). These are exceptional cases, though, and
should be considered as such.

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 and devfs - The final word

[Andreas Schwab]

Mark Mielke <mark@mark.mielke.cc> writes:

> There are a few cases that we might be forced to maintain regular
> numbers: mkfifo() creates a named pipe, and bind() creates a named
> socket.

Neither fifos nor sockets are devices.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: udev and devfs - The final word

[Mark Mielke]

On Mon, Jan 05, 2004 at 05:36:09PM +0100, Andreas Schwab wrote:
> Mark Mielke <mark@mark.mielke.cc> writes:
> > There are a few cases that we might be forced to maintain regular
> > numbers: mkfifo() creates a named pipe, and bind() creates a named
> > socket.
> Neither fifos nor sockets are devices.

Well, then, as long as things like this don't break... :-)

Other than backing up /dev, does anybody have *real* cases where a
program assumes major:minor is consistent across reboots? We should
start notifying the authors now... NFS seems to be one, given the
explanation offered for how fsid's are derived...

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 and devfs - The final word

[Daniel Jacobowitz]

On Sun, Jan 04, 2004 at 06:52:56PM -0800, Linus Torvalds wrote:
> 
> 
> On Sun, 4 Jan 2004, Andries Brouwer wrote:
> > 
> > Surprise! Are you leaving POSIX? Or ditching NFS?
> > Or demanding that NFS servers must never reboot?
> 
> Ok, Andries, time for you to take a deep breath, and calm down. Because 
> your arguments are getting ridiculous in the extreme.
> 
> A NFS server is sure as hell not going to export _its_ dynamic /dev to its 
> clients. That would be not just stupid, but crazy. Next you tell me that 
> you were using devfs and exporting that over NFS. 
> 
> A NFS server is going to export something _totally_ different than its own 
> /dev directory - it needs to be _client_-specific anyway. That's true with 
> stable numbers too, btw - ever tried to mount a Solaris /dev on a Linux 
> client? No workee.

I think you two are talking straight past each other.  Andries is
talking about the fsid, which is determined by the NFS server, based on
its idea of the device number of the filesystem underlying the exported
directory.  Right now, I can reboot my host system, and when it comes
up then the NFS directories it exports to clients will have the same
fsid.  With random device numbers it won't work; after rebooting the
NFS server all clients will be forced to explicitly unmount and
remount.

Now, it seems to me that this isn't much of an argument against random
device numbers.  Have userspace set a UUID for the device if you want,
and use that in the fsid instead.  But that's the argument; it has
nothing to do with the NFS server exporting its /dev.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: udev and devfs - The final word

[Linus Torvalds]

On Sun, 4 Jan 2004, Daniel Jacobowitz wrote:
> 
> I think you two are talking straight past each other.  Andries is
> talking about the fsid, which is determined by the NFS server, based on
> its idea of the device number of the filesystem underlying the exported
> directory.  Right now, I can reboot my host system, and when it comes
> up then the NFS directories it exports to clients will have the same
> fsid.  With random device numbers it won't work; after rebooting the
> NFS server all clients will be forced to explicitly unmount and
> remount.

Ahh. I'll buy into that, and yes, this is an example of something that 
needs to be fixed. 

It shouldn't be fixed by saying "device numbers have to be stable across 
reboots", because the fact is, we're most likely going to have storage 
that is really really hard to enumerate in a repeatable fashion.

So the _proper_ thing to do is to have the NFS server not use the device 
number as part of fsid. It should use the _stable_ UUID of the filesystem 
or some similar label.

And it should do that exactly because the device number isn't as stable as 
NFS exporting would like it to be. Exactly because things like network- 
attached disks etc.  How would you otherwise export a disk that perhaps 
gets its address from DHCP? 

[ I incredulously asked a NetApp person why you'd ever want to expose the
  _disk_ over ethenet, rather than just have the NAS device export a
  filesystem of its own. It turns out that some people really want to just
  see a block device, either because Windows sucks at network filesystems
  or because they want to do things like databases onto them. The point
  being that once you do that, you'll likely want to export the thing as
  an SMB share from the thing that "owns" the disk. 

  So you would literally have a _disk_ whose IP address changed depending 
  on what other machines were booted on the same network. ]

Issues like this is also why Linux vendors have already started doing
things like "mount by label" - because disks have a nasty tendency to move
around, and specifying the fstab contents (or "root=xxx" on the kernel
command line) with physical location or similar just doesn't work all
that well. It happens today with things like USB2 or firewire disks. They 
get moved around, and they get a new device number.

It's still not _common_, but it's slowly getting there.

> Now, it seems to me that this isn't much of an argument against random
> device numbers.  Have userspace set a UUID for the device if you want,
> and use that in the fsid instead.  But that's the argument; it has
> nothing to do with the NFS server exporting its /dev.

I buy into that, and I agree 100% with you that this is just a case where 
you should use a UUID.

		Linus

Re: udev and devfs - The final word

[viro]

On Sun, Jan 04, 2004 at 07:33:16PM -0800, Linus Torvalds wrote:
> Ahh. I'll buy into that, and yes, this is an example of something that 
> needs to be fixed. 
> 
> It shouldn't be fixed by saying "device numbers have to be stable across 
> reboots", because the fact is, we're most likely going to have storage 
> that is really really hard to enumerate in a repeatable fashion.
> 
> So the _proper_ thing to do is to have the NFS server not use the device 
> number as part of fsid. It should use the _stable_ UUID of the filesystem 
> or some similar label.

... and we already have a way to specify it explicitly.  Which, BTW, allows
to take server down, copy exported fs from failing IDE disk to SCSI one and
reexport.  With clients remaining happy with you.  Remember discussions
circa 2.5.50 or so about that stuff?

So we have tools for that.  And it's 100% OK to say "if you are doing NFS
export of filesystem that lives on $new_weird_device, explicit fsid= is
not just a good idea, it's a must-have".

What is _not_ OK, though, is to have folks suddenly see /dev/hda3 changing
its device number - then we would break existing setups that worked all
along; even if admin can fix the breakage, it's not a good thing to do.

Re: udev and devfs - The final word

[Linus Torvalds]

On Mon, 5 Jan 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
> 
> What is _not_ OK, though, is to have folks suddenly see /dev/hda3 changing
> its device number - then we would break existing setups that worked all
> along; even if admin can fix the breakage, it's not a good thing to do.

Ehh, it will actually happen.

If nothing else, things like SATA will end up meaning that the device you 
were used to seeign as /dev/hdc will suddenly show up as /dev/scd0 
instead. Just because you changed the cabling while you upgraded to a 
newer version of your CD-ROM drive.

And the thing is, with fs labels and udev, even "existing systems" really
shouldn't much care.

Now, we'd probably not want to force the switch, but I do suspect we'll 
have exactly this as a switch in the "Kernel Debugging Config" section. 
Where even _common_ things like disks could end up with per-bootup values. 
Just to verify that every part of the system ends up having it right.

Think of it this way: RedHat not that long ago decided to break with a
_lot_ of tradition by switching over to UTF-8 as the common text encoring.  
It broke some _major_ programs in how they dealt with "simple" things like
keyboard input that had worked for literally _decades_.

And you could switch it off if you really wanted to, but quite frankly, it 
wasn't even a simple choice in the install. You had to know what you were 
doing to switch it off.

And the thing is, that is _the_ single thing that cleaned up a lot of 
remaining problems wrt UTF-8 on Linux. Yes, almost all of them had been 
solved already, or RH wouldn't have dared do the switch. But to get there 
all the way, you had to literally force the cut-over.

(Yeah, I'm a bad person, and I personally went back to the C locale,
because "pine" still doesn't get UTF-8 right, and nobody is apparently
ever going to fix it. Oh, well. But at least I know I'm doing something
_wrong_, which in itself is a good thing.).

		Linus

Re: udev and devfs - The final word

[viro]

On Sun, Jan 04, 2004 at 08:02:20PM -0800, Linus Torvalds wrote:
> 
> 
> On Mon, 5 Jan 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
> > 
> > What is _not_ OK, though, is to have folks suddenly see /dev/hda3 changing
> > its device number - then we would break existing setups that worked all
> > along; even if admin can fix the breakage, it's not a good thing to do.
> 
> Ehh, it will actually happen.
> 
> If nothing else, things like SATA will end up meaning that the device you 
> were used to seeign as /dev/hdc will suddenly show up as /dev/scd0 
> instead. Just because you changed the cabling while you upgraded to a 
> newer version of your CD-ROM drive.

If I open the damn box, I sure as hell can be bothered to edit stuff in
/etc...

> And the thing is, with fs labels and udev, even "existing systems" really
> shouldn't much care.
> 
> Now, we'd probably not want to force the switch, but I do suspect we'll 
> have exactly this as a switch in the "Kernel Debugging Config" section. 
> Where even _common_ things like disks could end up with per-bootup values. 
> Just to verify that every part of the system ends up having it right.

Then we'd better have a very good idea of the things that are going to
break.  Note that right now even late-boot code in kernel itself will
break on that - there are explicit checks for ROOT_DEV==MKDEV(2,0),
all sorts of weird crap deep in the bowels of arch/ppc/*/*, etc.

It won't be an easy transition - I know that Greg is very optimistic
about it, but there will be a *lot* of crap to take care of.  In theory
getting bigger dev_t should've been very straightforward, but if you
check what really had been involved...

ObOtherStraightforwardThings: net_device refcounting.  Take a look at
Jeff's queue someday - by now it's one big merge short of getting it
right for practically all drivers.  1.9Mb total + 247Kb pending patches
here.  Several hundreds changesets, practically all of them fixing
exploitable holes.  And yes, most of them had been bugs all along -
since 2.2 if not earlier.  Sure, that made things better, but if somebody
comes along and makes similar "fun" necessary for e.g. ALSA...

> because "pine" still doesn't get UTF-8 right, and nobody is apparently
> ever going to fix it. Oh, well. But at least I know I'm doing something
> _wrong_, which in itself is a good thing.).

Heh.  Took you long enough - "using pine" should've been a dead giveaway
from the very beginning ;-)

Re: udev and devfs - The final word

[Linus Torvalds]

On Mon, 5 Jan 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:

> > If nothing else, things like SATA will end up meaning that the device you 
> > were used to seeign as /dev/hdc will suddenly show up as /dev/scd0 
> > instead. Just because you changed the cabling while you upgraded to a 
> > newer version of your CD-ROM drive.
> 
> If I open the damn box, I sure as hell can be bothered to edit stuff in
> /etc...

Actually, not necessarily.

The thing is, _the_ most common reason I have for opening the box is that 
the effing thing started having problems.

At which point I want to just remove the disk, move it to another box, and 
boot up the other box.

And THAT is exactly the kind of situation where I sure as hell don't want
to care exactly where the disk was. I can't "prepare" for it by editing
files in /etc, since I don't know that the CPU fan or whatever is going to
die on me.

And this is _exactly_ why we should try to get away from device numbering
having any meaning. Because if we do this right, something like the CPU
fan dying, and me moving a disk to a new machine that has SATA (with the
disk having both SATA and PATA connectors), I shouldn't need to even
_think_ about it.

That's where "mount by label" does part of the job. But if the system is 
_always_ set up to do things like NFS exports according to some separate 
UUID, that too would "just work".

There's a lot to be said for "just work".  Even if sometimes it takes some 
pain when you break old (and broken) assumptions.

> > because "pine" still doesn't get UTF-8 right, and nobody is apparently
> > ever going to fix it. Oh, well. But at least I know I'm doing something
> > _wrong_, which in itself is a good thing.).
> 
> Heh.  Took you long enough - "using pine" should've been a dead giveaway
> from the very beginning ;-)

Those are them fighting words.

But since you brought it up: do you actually have anything else that can
open a remote IMAP file with a few thousand messages without taking ages
for it, and that you don't have to mouse around with? I'd like a graphical
interface for configuring stuff etc, but I sure as hell don't want to find
some f*ing icon to save a few messages that I selected in-order to my
"doit" queue or go to the next one, or pipe the thing to a shell-script,
or any number of things that are my actual _job_.

And the "no mousing" means that I don't want to have some popup window 
that asks me what file I want to save into or similar crap. I can type 
fast enough if I stay on the keyboard and can focus on one part of the 
screen, but if I have to switch my focus around, I'm a goner.

On a related matter, I'm probably a retard, but I've tried alternatives to
"trn" too, and there really aren't any. None of the graphical news readers
can show me one full page of threads, select the 3-4 threads from _that_
one page that I want (from the keyboard), and then kill _that_ one page.
Not the whole newsgroup: only the part that shows in the window at that
time.

In "trn", the magic command is capital-D, for "discard".

		Linus

Re: udev and devfs - The final word

[viro]

On Sun, Jan 04, 2004 at 08:52:56PM -0800, Linus Torvalds wrote:
 
> That's where "mount by label" does part of the job. But if the system is 
> _always_ set up to do things like NFS exports according to some separate 
> UUID, that too would "just work".

mount by label does part of the job, until you decide to use dd(1) to copy
a disk.  At which point you have, AFAICS, no way tell which copy will get
mounted.
 
> Those are them fighting words.
> 
> But since you brought it up: do you actually have anything else that can
> open a remote IMAP file with a few thousand messages without taking ages
> for it, and that you don't have to mouse around with? I'd like a graphical
> interface for configuring stuff etc, but I sure as hell don't want to find
> some f*ing icon to save a few messages that I selected in-order to my
> "doit" queue or go to the next one, or pipe the thing to a shell-script,
> or any number of things that are my actual _job_.

I prefer to ssh to another box and use mutt.  Seriously, I've made a mistake
of reading imapd source and that was enough to decide that I'm _not_ touching
uw-<anything> and that protocol in general unless I really have no other
options.  So far I've managed to avoid that...

> On a related matter, I'm probably a retard, but I've tried alternatives to
> "trn" too, and there really aren't any.

Same here.  There are things about trn command set I'd prefer to see changed,
but it's better than other newsreaders I've seen...

Re: udev and devfs - The final word

[Greg KH]

On Sun, Jan 04, 2004 at 08:52:56PM -0800, Linus Torvalds wrote:
> 
> But since you brought it up: do you actually have anything else that can
> open a remote IMAP file with a few thousand messages without taking ages
> for it, and that you don't have to mouse around with? I'd like a graphical
> interface for configuring stuff etc, but I sure as hell don't want to find
> some f*ing icon to save a few messages that I selected in-order to my
> "doit" queue or go to the next one, or pipe the thing to a shell-script,
> or any number of things that are my actual _job_.

mutt can provide a path for a recovering pine addict.  I did that a
number of years ago and have been quite happy since.  I can't vouch for
its IMAP speeds (seems to be fast enough for me, as long as I don't try
to do a filter on a large IMAP folder), but the other tasks you do
(selecting, piping, etc.) work very well.

I even think there's a mutt config file that duplicates all of the
default pine keystrokes just to make moving easier.

The message threading was reason enough for me to switch, although I've
heard rumors that pine can handle that now.

thanks,

greg k-h

Re: udev and devfs - The final word

[Vojtech Pavlik]

On Sun, Jan 04, 2004 at 11:47:17PM -0800, Greg KH wrote:

> > But since you brought it up: do you actually have anything else that can
> > open a remote IMAP file with a few thousand messages without taking ages
> > for it, and that you don't have to mouse around with? I'd like a graphical
> > interface for configuring stuff etc, but I sure as hell don't want to find
> > some f*ing icon to save a few messages that I selected in-order to my
> > "doit" queue or go to the next one, or pipe the thing to a shell-script,
> > or any number of things that are my actual _job_.
> 
> mutt can provide a path for a recovering pine addict.  I did that a
> number of years ago and have been quite happy since.  I can't vouch for
> its IMAP speeds (seems to be fast enough for me, as long as I don't try
> to do a filter on a large IMAP folder), but the other tasks you do
> (selecting, piping, etc.) work very well.

Mutt with IMAP is rather bearable even on a GPRS connection (40kbps,
1sec latency). On a 100baseTX it's not distinguishable from local
operation.

One thing missing in mutt is a persistent message and message header
cache - opening a folder can take a lot of time over a slow connection.
But there is a patch at least for the message header cache persistence
floating on the 'net somewhere.

Another thing that bugs me often in mutt is its inability to service
keystrokes while doing something else (like checking for new mail over
IMAP with a slow link). It becomes unresponsive until that task is done.

> I even think there's a mutt config file that duplicates all of the
> default pine keystrokes just to make moving easier.
> 
> The message threading was reason enough for me to switch, although I've
> heard rumors that pine can handle that now.
> 
> thanks,
> 
> greg k-h
> -
> 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/

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: udev and devfs - The final word

[Theodore Ts'o]

On Mon, Jan 05, 2004 at 12:15:56PM +0100, Vojtech Pavlik wrote:
> 
> Mutt with IMAP is rather bearable even on a GPRS connection (40kbps,
> 1sec latency). On a 100baseTX it's not distinguishable from local
> operation.

Hmm... I've tried using mutt/IMAP over GPRS connection, and I find it
extremely unpleasant, myself.  My solution is to use isync to provide
a local cached copy of the IMAP server on my laptop, and then run mutt
against the local cached copy.  

I have a patch to isync which allows it to issue multiple IMAP
commands in parallel (instead of operating in lockstep fashion):

http://bugs.debian.org/cgi-bin/bugreport.cgi//tmp/async-imap-patch?bug=226222&msg=3&att=1

With this patch, isync works very well, even over high latency, slow
speed links.

						- Ted

Re: udev and devfs - The final word

[Vojtech Pavlik]

On Mon, Jan 05, 2004 at 03:11:44PM -0500, Theodore Ts'o wrote:

> On Mon, Jan 05, 2004 at 12:15:56PM +0100, Vojtech Pavlik wrote:
> > 
> > Mutt with IMAP is rather bearable even on a GPRS connection (40kbps,
> > 1sec latency). On a 100baseTX it's not distinguishable from local
> > operation.
> 
> Hmm... I've tried using mutt/IMAP over GPRS connection, and I find it
> extremely unpleasant, myself.  My solution is to use isync to provide
> a local cached copy of the IMAP server on my laptop, and then run mutt
> against the local cached copy.  
> 
> I have a patch to isync which allows it to issue multiple IMAP
> commands in parallel (instead of operating in lockstep fashion):
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi//tmp/async-imap-patch?bug=226222&msg=3&att=1
> 
> With this patch, isync works very well, even over high latency, slow
> speed links.

That looks very nice. Now, if there were a way how to make the isync
IMAP connections go over a compressed ssh link (like I'm doing with
Mutt/IMAP) that'd be very cool.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: udev and devfs - The final word

[Theodore Ts'o]

On Mon, Jan 05, 2004 at 10:06:25PM +0100, Vojtech Pavlik wrote:
> 
> That looks very nice. Now, if there were a way how to make the isync
> IMAP connections go over a compressed ssh link (like I'm doing with
> Mutt/IMAP) that'd be very cool.
> 

The following in your .isyncrc file will do the trick:

Mailbox thunk
Box Inbox
Host thunk.org
Tunnel "socat SOCKS4A:127.0.0.1:thunk.org:143 STDIO"

You can also do this via secure IMAP, but then ssh's compression won't
be able to do much.  Nevertheless, I do this when synchronizing
against an IMAP server where I don't have ssh access, and where I want
the connection between the thunk.org and po14.mit.edu to be secured.
So I use the following syntax in .isyncrc to achieve to do this:

Mailbox Inbox
Box Inbox
Host imaps:po14.mit.edu
Tunnel "socat SOCKS4A:127.0.0.1:po14.mit.edu:993 STDIO"
UseSSLv2 yes
UseSSLv3 yes
UseTLSv1 yes

						- Ted

Re: udev and devfs - The final word

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]

On Monday 05 January 2004 15:06, Vojtech Pavlik wrote:
> On Mon, Jan 05, 2004 at 03:11:44PM -0500, Theodore Ts'o wrote:
> > On Mon, Jan 05, 2004 at 12:15:56PM +0100, Vojtech Pavlik wrote:
> > > Mutt with IMAP is rather bearable even on a GPRS connection (40kbps,
> > > 1sec latency). On a 100baseTX it's not distinguishable from local
> > > operation.
> >
> > Hmm... I've tried using mutt/IMAP over GPRS connection, and I find it
> > extremely unpleasant, myself.  My solution is to use isync to provide
> > a local cached copy of the IMAP server on my laptop, and then run mutt
> > against the local cached copy.
> >
> > I have a patch to isync which allows it to issue multiple IMAP
> > commands in parallel (instead of operating in lockstep fashion):
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi//tmp/async-imap-patch?bug=22
> >6222&msg=3&att=1
> >
> > With this patch, isync works very well, even over high latency, slow
> > speed links.
>
> That looks very nice. Now, if there were a way how to make the isync
> IMAP connections go over a compressed ssh link (like I'm doing with
> Mutt/IMAP) that'd be very cool.

You can run any tcp/ip service over ssh.

Tell isync that the imap server it's synchronizing with lives on the loopback 
interface, and then run a variant this little python script I use to check my 
email (adjusting the last line for your connection info).  (Note that the far 
end needs netcat.  If you haven't got it, try the version in busybox.)

Yeah, the script's a quick and dirty hack, but really easy to modify.  I have 
a more complicated one using SO_ORIGINAL_DEST and a lookup table if you 
prefer to setup some firewall rules and tell your imap server it lives in the 
192.168.x.x or 10.x.x.x address range...  But I've never gotten around to 
configuring my laptop to use it just to tunnel pop. :)

I keep meaning to put the full solution up on http://dvpn.sf.net, but nobody's 
pestered me about it. :)

Rob

[-- Attachment #2: boing.py --]
[-- Type: text/x-python, Size: 605 bytes --]

#!/usr/bin/python

import socket,struct,sys,os,signal

vpnip="127.0.0.1"
vpnport=int(sys.argv[1]) # 110 25

signal.signal(signal.SIGCHLD, lambda a,b: os.waitpid(-1,os.WNOHANG))

sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
sock.bind((vpnip,vpnport))
sock.listen(10)

while 1:
  try: (conn,addr)=sock.accept()
  except socket.error: continue

  if os.fork():
    conn.close()
    continue

  os.dup2(conn.fileno(),0)
  os.dup2(conn.fileno(),1)
  conn.close()
  sock.close()

  os.execvp("ssh",("ssh","-i","/home/landley/.ssh/id_dsa","landley@66.92.53.140","./netcat","192.168.1.31",str(vpnport)))

[OT] Re: udev and devfs - The final word

[Disconnect]

On Mon, 2004-01-05 at 19:14, Rob Landley wrote:
> You can run any tcp/ip service over ssh.
> 
> Yeah, the script's a quick and dirty hack, but really easy to modify.  I have 
> a more complicated one using SO_ORIGINAL_DEST and a lookup table if you 
> prefer to setup some firewall rules and tell your imap server it lives in the 
> 192.168.x.x or 10.x.x.x address range...  But I've never gotten around to 
> configuring my laptop to use it just to tunnel pop. :)

simpler:
ssh -L<local>:127.0.0.1:<remote> [-C] user@host

eg I forward imap from home (not accessible outside localhost) and
jabber from a second machine at home:
ssh -L143:localhost:143 -L5222:jabber:5222 -C dis@home

Then just point the client at localhost:143 (or 5222) and it 'just
works'. No python required. 

For an added bonus, run a script on the far side that does something
like:
 while /bin/true; do 
    if [ -f .dienow ]; then 
      rm -f .dienow
      exit
    else sleep 60
  done
and on the local side:
 while /bin/true; do 
   ssh -L1:localhost:2 etc user@host ./remotescript 
   sleep 1
   if [ -f .dienow ]; do 
     scp .dienow user@host: && rm -f .dienow
   done
  done

..respawn the ssh forwards until it finds ~/.dienow (-and- the current
ssh exits) and then kill off both sides.  Don't flood the system by
respawning ssh more than once per 1-2 seconds. (And who said you
couldn't vpn with shell? You can even add/remove ports along the way, if
you get creative.)

-- 
Disconnect <lkml@sigkill.net>

Re: udev and devfs - The final word

[Ed L Cashin]

Linus Torvalds <torvalds@osdl.org> writes:

...
> But since you brought it up: do you actually have anything else that can
> open a remote IMAP file with a few thousand messages without taking ages
> for it, and that you don't have to mouse around with? I'd like a graphical
> interface for configuring stuff etc, but I sure as hell don't want to find
> some f*ing icon to save a few messages that I selected in-order to my
> "doit" queue or go to the next one, or pipe the thing to a shell-script,
> or any number of things that are my actual _job_.

Don't you already use emacs?  Emacs has gnus!  Gnus now has nnimap, an
imap backend.

> And the "no mousing" means that I don't want to have some popup window 
> that asks me what file I want to save into or similar crap. I can type 
> fast enough if I stay on the keyboard and can focus on one part of the 
> screen, but if I have to switch my focus around, I'm a goner.
>
> On a related matter, I'm probably a retard, but I've tried alternatives to
> "trn" too, and there really aren't any. None of the graphical news readers
> can show me one full page of threads, select the 3-4 threads from _that_
> one page that I want (from the keyboard), and then kill _that_ one page.
> Not the whole newsgroup: only the part that shows in the window at that
> time.

Man, you sound so ready for gnus.  It does nntp as well.

-- 
--Ed L Cashin            |   PGP public key:
  ecashin@uga.edu        |   http://noserose.net/e/pgp/

Re: udev and devfs - The final word

[Eric W. Biederman]

viro@parcelfarce.linux.theplanet.co.uk writes:

> On Sun, Jan 04, 2004 at 08:02:20PM -0800, Linus Torvalds wrote:
> > Now, we'd probably not want to force the switch, but I do suspect we'll 
> > have exactly this as a switch in the "Kernel Debugging Config" section. 
> > Where even _common_ things like disks could end up with per-bootup values. 
> > Just to verify that every part of the system ends up having it right.
> 
> Then we'd better have a very good idea of the things that are going to
> break.  Note that right now even late-boot code in kernel itself will
> break on that - there are explicit checks for ROOT_DEV==MKDEV(2,0),
> all sorts of weird crap deep in the bowels of arch/ppc/*/*, etc.

/sbin/lilo and possibly some of the other bootloaders.  Relationships
between devices are a challenge to work with.  How do you go from a
partition to it's actual block device etc.  I don't remember how many
major numbers lilo has hard coded, I just remember looking at it once
and realizing I couldn't think of a better way to accomplish what it
was trying to do.

Eric

Re: udev and devfs - The final word

[Greg KH]

On Mon, Jan 05, 2004 at 04:38:30AM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> 
> Then we'd better have a very good idea of the things that are going to
> break.  Note that right now even late-boot code in kernel itself will
> break on that - there are explicit checks for ROOT_DEV==MKDEV(2,0),
> all sorts of weird crap deep in the bowels of arch/ppc/*/*, etc.
> 
> It won't be an easy transition - I know that Greg is very optimistic
> about it, but there will be a *lot* of crap to take care of.

Oh I know it's going to be tough, and there's going to be a lot of crap
to take care of, but in the end, I think it will be worth it...hopefully
if I'm still sane then...

> ObOtherStraightforwardThings: net_device refcounting.  Take a look at
> Jeff's queue someday - by now it's one big merge short of getting it
> right for practically all drivers.  1.9Mb total + 247Kb pending patches
> here.  Several hundreds changesets, practically all of them fixing
> exploitable holes.  And yes, most of them had been bugs all along -
> since 2.2 if not earlier.  Sure, that made things better, but if somebody
> comes along and makes similar "fun" necessary for e.g. ALSA...

Yeah, ALSA scares me, along with the input layer code.  I had dreams of
easily converting them to use proper refcounting, but now know there's
no way that would be an easy conversion and have pretty much given up on
it.  For 2.6 at least.  

That's why my "simple_class" patch will have to be a band-aid for now to
get sysfs representation for those types of devices.

thanks,

greg k-h

Re: udev and devfs - The final word

[Pavel Machek]

Hi!

> If nothing else, things like SATA will end up meaning that the device you 
> were used to seeign as /dev/hdc will suddenly show up as /dev/scd0 
> instead. Just because you changed the cabling while you upgraded to a 

I do not see easy solution for cdroms... UUID is not going to work there...
				Pavel

Re: udev and devfs - The final word

[Andries Brouwer]

On Sun, Jan 04, 2004 at 07:33:16PM -0800, Linus Torvalds wrote:

[A mailbox full of messages, too many to reply to.
Yes, Daniel Jacobowitz understood that I referred to fsid in the NFS case:

  There is a great variation here in what various servers and clients do,
  but roughly speaking filehandles tend to contain a fsid, and this fsid
  often (no fsid= given) involves (major,minor,ino).

No, I have not talked this year about exporting /dev. Also interesting.
Yes, as I said, one can avoid NFS problems by giving fsid=.
It is similar elsewhere. A thousand minor problems are caused by
unstable device numbers. All annoying, each can be solved easily
once one has figured out what goes wrong and why. That is why I say
"preferably stable across reboots".]


What remains to be said?

Linus, let me try a bit more to address what I see as a misconception
in your posts.

> It shouldn't be fixed by saying "device numbers have to be stable across 
> reboots", because the fact is, we're most likely going to have storage 
> that is really really hard to enumerate in a repeatable fashion.

You have this strange hangup concerning "enumerate", and then keep
repeating to others that enumerating is impossible, and that therefore
stable device numbers are impossible, and that consequently, since we
cannot have stable device numbers expecting them to be stable is broken.

It is an old misconception - I recall you telling me how many billion years
an "ls /dev" would take with 64-bit device numbers.

No - I never advocated "find a device number by enumeration".
Quite the opposite, I advocated "use a hash of the serial number
as the device number of a disk". And more generally, "it is the
driver's job to assign a device number".

So it is not difficult at all to give this network attached storage
a stable device number.

And if one can, there is no reason not to do so.
It may even allow udev to give stable names as well.


Andries

Re: udev and devfs - The final word

[Linus Torvalds]

On Mon, 5 Jan 2004, Andries Brouwer wrote:
> 
> You have this strange hangup concerning "enumerate", and then keep
> repeating to others that enumerating is impossible, and that therefore
> stable device numbers are impossible, and that consequently, since we
> cannot have stable device numbers expecting them to be stable is broken.

Right.

> It is an old misconception - I recall you telling me how many billion years
> an "ls /dev" would take with 64-bit device numbers.

No. When I talk abotu "enumerate", I do not mean "give numbers starting at
1". In the mathematical sense it means that you _can_ number them with
integers, not that it is necessarily a sequence from 1...n.

For example, PCI device slots are "enumerable". That doesn't mean that we
give them numbers 1..n, it only means that we can encode their address in
a single number. So if everything was a PCI slot, we could enumerate the
whole address space, and "stable" device numbers would be possible (they'd
be stable by _slot_, not by actual device, but that's good enough for some
people).

But the thing is, some things you simply _cannot_ number. For example, a
two-dimensional space is innumerable - you need more than one integer
number to look things up.  So is the set of real numbers (but not the set 
of fractions), etc etc.

It boils down to not how many devices there can be, but to whether there 
is any way to "walk the space of devices".

And there fundamentally isn't. And _that_ is the basic issue: if you
_cannot_ number a space, you cannot have a stable device number.

> No - I never advocated "find a device number by enumeration".
> Quite the opposite, I advocated "use a hash of the serial number
> as the device number of a disk". And more generally, "it is the
> driver's job to assign a device number".

There _is_ no such number as you are talking about. You are talking pure 
theory that has nothing to do with reality. There are no "serial numbers".

Don't you see? This is what "enumeration" is all about. You are assuming a 
model that simply DOES NOT EXIST. Your "serial numbers" are exactly what 
I'm talking about when I say "enumerate". Whenever you claim that a device 
has a "serial number", you literally claim that the device space is 
enumerable, and that is what I have been telling you from day one IS NOT 
TRUE!

Whether you then hash the serial number or not is totally irrelevant: an 
enumeration of hashes is still an enumeration.

Devices do not _have_ serial numbers. They are not enumerable. In other
words, they do not have some kind of explicit identity that we can use to
give them numbers. That is what "innumerable" MEANS, and that is why I 
have been harping on the issue.

Please. Where do you think those numbers would come from?

So I claim as an axiom for device numbering that devices are not
enumerable, and that this _fundamentally_ leads to the corollary that you 
cannot give them stable numbers. Not with hashes, not with _anything_. The 
best you can do is to _literally_ just give them some per-session unique 
integer that is simply the discovery ordering, nothing more.

> So it is not difficult at all to give this network attached storage
> a stable device number.

It is not only difficult, it is fundamentally _impossible_.

> And if one can, there is no reason not to do so.
> It may even allow udev to give stable names as well.

My point is that for the subset of devices that _do_ have serial numbers 
(and it is a subset, nothing more), udev can then use those serial numbers 
to have a stable pathname to the device. But it's a _pathname_, not a 
number.

And for devices that don't have serial numbers, udev can try to use other 
heuristics instead to give those stable names. Sometimes those other 
heuristics would be looking at the actual _content_ of the thing.

For example, if you wanted to, you could make udev do a cddb lookup on the
CD-ROM, and use that as the pathname, so that when you insert your
favorite audio disk, it will always show up in the same place, regardless 
of whether you put it in the DVD slot or the CD-RW drive. 

[ Yeah, that sounds like a singularly silly thing to do, but it's a good 
  example of something where there is no actual serial number, but you can 
  "identify" it automatically through its contents, and name it stably 
  according to that. ]

That is indeed the point of udev.  Doing things that the kenrel 
_obviously_ should not do.

			Linus

Re: udev and devfs - The final word

[Vojtech Pavlik]

On Mon, Jan 05, 2004 at 08:13:26AM -0800, Linus Torvalds wrote:

> But the thing is, some things you simply _cannot_ number. For example, a
> two-dimensional space is innumerable - you need more than one integer
> number to look things up.  So is the set of real numbers (but not the set 
> of fractions), etc etc.

Two dimensional discrete space (*) is enumerable. Just start at [0,0]
and assign numbers going around the center in a growing spiral (**).
That way you assign a number to every point in that space. This is very
similar to the trick used to demonstrate fractions are enumerable.

(*)  The one where you can use two integers to look things up.
(**) Assuming the coordinates can be negative. For non-negative
     it's even easier.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: udev and devfs - The final word

[Linus Torvalds]

On Mon, 5 Jan 2004, Vojtech Pavlik wrote:
> 
> Two dimensional discrete space (*) is enumerable.

Yeah, I'm sorry - you're the second person to point it out, and I really 
knew that but had all the wrong associations (I was thinking of the 
complex plane, not a discrete thing).

> (**) Assuming the coordinates can be negative. For non-negative
>      it's even easier.

It ends up being exactly the same pattern as for fractions (ignoring 0,
which just shifts it), which I explicitly listed as being enumerable, so I
was just being stupid.

I can only say that it's been some time since I actually did my early 
math.. 

		Linus

Re: udev and devfs - The final word

[Davide Libenzi]

On Mon, 5 Jan 2004, Vojtech Pavlik wrote:

> On Mon, Jan 05, 2004 at 08:13:26AM -0800, Linus Torvalds wrote:
> 
> > But the thing is, some things you simply _cannot_ number. For example, a
> > two-dimensional space is innumerable - you need more than one integer
> > number to look things up.  So is the set of real numbers (but not the set 
> > of fractions), etc etc.
> 
> Two dimensional discrete space (*) is enumerable. Just start at [0,0]
> and assign numbers going around the center in a growing spiral (**).
> That way you assign a number to every point in that space. This is very
> similar to the trick used to demonstrate fractions are enumerable.

Vojtech, a spiral (in the math sense) won't work because whatever 
continuos function you choose for the radius, you are going to skip 
integers when the radius grows (and duplicate them when it's small). Also, 
IIRC, fractions are enumerable because they're a mapping from two 
enumerable spaces (integers): F = F(I1, I2) = I1 / I2.



- Davide

Re: udev and devfs - The final word

[Linus Torvalds]

On Mon, 5 Jan 2004, Davide Libenzi wrote:
> 
> Vojtech, a spiral (in the math sense) won't work

It's not a spiral in that sense - it's just that the pattern you get when
walking the "dots" looks like a spiral.

> Also, IIRC, fractions are enumerable because they're a mapping from two
> enumerable spaces (integers): F = F(I1, I2) = I1 / I2.

Which is exactly the thing that Vojtech is really talking about: the
enumerable space of a _discrete_ two-dimensional shape, ie folding two
enumerable spaces onto one.

The negative values don't matter, since you can effectively enumerate both
ways starting from zero (ie the full set of integers is not any less
enumerable than the positive numbers are):

	0, 1, -1, 2, -2, 3, -3, ...

so it doesn't really matter if you only enumerate one quadrant (which is
effectively the same thing as enumerating fractions) or all four
quadrants.

The "spiral" pattern for a two-dimensional enumeration ends up being
something like

  (0,0) -> (1,0) -> (0,1) -> (-1,0) -> (0, -1) -> (1,-1) -> (2,0) -> ...

(do it on a graph paper and it's obvious, the above is probably wrong 
since I'm trying to visualize it)


		Linus

Re: udev and devfs - The final word

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

On Mon, Jan 05, 2004 at 09:52:45AM -0800, Davide Libenzi wrote:
> On Mon, 5 Jan 2004, Vojtech Pavlik wrote:
> 
> > On Mon, Jan 05, 2004 at 08:13:26AM -0800, Linus Torvalds wrote:
> > 
> > > But the thing is, some things you simply _cannot_ number. For example, a
> > > two-dimensional space is innumerable - you need more than one integer
> > > number to look things up.  So is the set of real numbers (but not the set 
> > > of fractions), etc etc.
> > 
> > Two dimensional discrete space (*) is enumerable. Just start at [0,0]
> > and assign numbers going around the center in a growing spiral (**).
> > That way you assign a number to every point in that space. This is very
> > similar to the trick used to demonstrate fractions are enumerable.
> 
> Vojtech, a spiral (in the math sense) won't work because whatever 
> continuos function you choose for the radius, you are going to skip 
> integers when the radius grows (and duplicate them when it's small). Also, 
> IIRC, fractions are enumerable because they're a mapping from two 
> enumerable spaces (integers): F = F(I1, I2) = I1 / I2.

   I think he meant something like this:

( 0,  0)
( 1,  0)
( 0,  1)
(-1,  0)
( 0, -1)
( 2,  0)
( 1,  1)
( 0,  2)
(-1,  1)
(-2,  0)
(-1, -1)
etc.

   Rationals are countable since they're the product of the integers
(numerator) and the natural numbers without zero (denominator). You
can count them in a similar way to the above "spiral", making sure
that you don't count 1/2 and 2/4 as two different numbers. :)

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
      --- Try everything once,  except incest and folk-dancing. ---      

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: udev and devfs - The final word

[Paul Rolland]

Hello,

> > Two dimensional discrete space (*) is enumerable. Just 
> start at [0,0]
> > and assign numbers going around the center in a growing spiral (**).
> > That way you assign a number to every point in that space. 
> This is very
> > similar to the trick used to demonstrate fractions are enumerable.
> 
> Vojtech, a spiral (in the math sense) won't work because whatever 
> continuos function you choose for the radius, you are going to skip 
> integers when the radius grows (and duplicate them when it's 
> small). Also, 
> IIRC, fractions are enumerable because they're a mapping from two 
> enumerable spaces (integers): F = F(I1, I2) = I1 / I2.
> 
No, I think Vojtech was meaning this kind of spiral and
enumeration :

  ...16 15 14 13
     5  4  3  12
     6  1  2  11
     7  8  9  10  

and so on... The spiral in not to be taken in the math sense...

Regards,
Paul

Re: udev and devfs - The final word

[Andries Brouwer]

On Mon, Jan 05, 2004 at 08:13:26AM -0800, Linus Torvalds wrote:

> > You keep repeating that enumerating is impossible, and that therefore
> > stable device numbers are impossible, and that consequently, since we
> > cannot have stable device numbers expecting them to be stable is broken.
> 
> Right.

> When I talk about "enumerate", I do not mean "give numbers starting at 1".
> It boils down to not how many devices there can be, but to whether there 
> is any way to "walk the space of devices".

Yes, that is what one commonly calls to enumerate.  Let us say,
an effective way, given some integer, to find the associated device.

[You can leave the mathematics out - this enumerable is not the same as
denumerable or countable. The set of devices on earth is finite.]

> And there fundamentally isn't. And _that_ is the basic issue: if you
> _cannot_ number a space, you cannot have a stable device number.

If there is no effective way to find a disk given some number,
there may very well be an effective way to find a number given some disk.
And indeed, there usually is.

> There are no "serial numbers".
> Please. Where do you think those numbers would come from?

Most of my devices do have them...

> My point is that for the subset of devices that _do_ have serial numbers 

Ah, wait! You also have heard about devices with serial numbers! Good!
It is those devices I was talking about. Remember? ["important special case"]

> udev can then use those serial numbers to have a stable pathname

True. Provided that it knows how to get them.
The kernel driver knew all about the device.
Must udev also know all about all possible devices? Do I/O to these devices?
Or must sysfs export all data that could possibly be used?

Andries

Re: udev and devfs - The final word

[Linus Torvalds]

On Mon, 5 Jan 2004, Andries Brouwer wrote:
> 
> > udev can then use those serial numbers to have a stable pathname
> 
> True. Provided that it knows how to get them.

And that is the _only_ thing that the "device number" actually is. It is a 
cookie that the kernel has allocated for the device that the kernel knows 
about. Nothing more.

Go back and read my emails. Device numbers cannot have any meaning, they 
literally are _only_ useful as cookies. 

> The kernel driver knew all about the device.

No. The kernel driver knows _of_ the device, it does not know "all about"  
the device. And that's a big difference.

Quite often the kernel only knows that it found "a device". It has very
limited knowledge about what the device is, and what it can do. That's why 
we have tools like "smartd" etc, that know a lot more about devices than 
the kernel often does.

In particular, the kernel driver knows _nothing_ about potential serial
numbers or how to read them for different classes of devices.

> Must udev also know all about all possible devices? Do I/O to these devices?
> Or must sysfs export all data that could possibly be used?

There is nothing to export. You seem to imply that the kernel somehow
knows more than user space, but the reverse is generally true. 

In particular, the kernel should never have policy encoded in it, and 
naming of a device is about pretty much nothing _but_ policy. Stuff that 
the kernel literally has _zero_ knowledged about.

Yes, the kernel knows the physical location, but that doesn't actually 
help the kernel itself. It's exported through sysfs, yes, and udev, 
together with the hotplug stuff, can be used to make up the "stable name". 

Have you even _tried_ udev? Udev can do exactly things like find UUID's 
off disks - something the kernel doesn't have a _clue_ about. When the 
kernel sees a disk, it's just a disk. The kernel doesn't know if there is 
an UUID embedded on the disk, and the kernel SHOULD NOT HAVE A POLICY to 
try to find one.

But for user space, the thing is trivially done: the kernel will notify
user space about the fact that it found a device (without necessarily
knowing what the heck the device is - quite common with USB or specialty
SCSI devices). The kernel pretty much doesn't know _anything_ about things
like laser range finders, cameras etc. It ends up classifying the device 
on a very rough level, nothing more.

And without knowing practically _anythign_ about the device, it still has
to allocate a device number. Exactly so that somebody else can come around
and poke at it, and maybe know that "ahh, this device is a USB-attached
camera" or similar.

Do you not see that fundamental issue? The kernel has to allocate a number 
before a UUID or anythign else is necessarily available. 

The UUID/serial number/type policy comes _later_.

		Linus

Re: udev and devfs - The final word

[Shawn]

Linus is correct. I say this somewhat because I find his arguments to
make perfect sense in a philosophical way, but more because it is his
kernel.

Anyway, I'll weigh in with my 0.02 pesos:
Right now, as things are, hardware devices' numbers are not very stable
as it is. Detection order can and will change, and you should not rely
on them being the same. PERIOD.

Having said that, I will say that they are /somewhat/ stable. You can,
in general, say 'fdisk /dev/hdb' and be editing the same block device's
partition table... That is, if nothing has changed in the BIOS or
hardware or kernel or....

Now, correct me if I'm wrong, but I don't believe we are expecting
device numbers to change nearly every time you reboot given there are no
hardware changes with a dynamic numbering scheme, right?

I would, as an admin, have need for distinguishing between my 4
identical SATA hard drives with identical partition tables without
having to resort to examining UUIDs, serial number or FS labels by hand,
especially if I dd(1) stuff between them. I understand this is not as
simple as with ide(0-N)(pri|sec)(master|slave) (ignoring that ide(0-N)
could be detected in arbitrary order) as SATA is different.

As an admin, would I at least theoretically have /some/ consistency if
merely for my own sanity when dealing with block devices by hand (I do
need to setup LVM stuff from time to time)??

On Mon, 2004-01-05 at 14:38, Linus Torvalds wrote:
> On Mon, 5 Jan 2004, Andries Brouwer wrote:
> > 
> > > udev can then use those serial numbers to have a stable pathname
> > 
> > True. Provided that it knows how to get them.
> 
> And that is the _only_ thing that the "device number" actually is. It is a 
> cookie that the kernel has allocated for the device that the kernel knows 
> about. Nothing more.
> 
> Go back and read my emails. Device numbers cannot have any meaning, they 
> literally are _only_ useful as cookies. 
> 
> > The kernel driver knew all about the device.
> 
> No. The kernel driver knows _of_ the device, it does not know "all about"  
> the device. And that's a big difference.
> 
> Quite often the kernel only knows that it found "a device". It has very
> limited knowledge about what the device is, and what it can do. That's why 
> we have tools like "smartd" etc, that know a lot more about devices than 
> the kernel often does.
> 
> In particular, the kernel driver knows _nothing_ about potential serial
> numbers or how to read them for different classes of devices.
> 
> > Must udev also know all about all possible devices? Do I/O to these devices?
> > Or must sysfs export all data that could possibly be used?
> 
> There is nothing to export. You seem to imply that the kernel somehow
> knows more than user space, but the reverse is generally true. 
> 
> In particular, the kernel should never have policy encoded in it, and 
> naming of a device is about pretty much nothing _but_ policy. Stuff that 
> the kernel literally has _zero_ knowledged about.
> 
> Yes, the kernel knows the physical location, but that doesn't actually 
> help the kernel itself. It's exported through sysfs, yes, and udev, 
> together with the hotplug stuff, can be used to make up the "stable name". 
> 
> Have you even _tried_ udev? Udev can do exactly things like find UUID's 
> off disks - something the kernel doesn't have a _clue_ about. When the 
> kernel sees a disk, it's just a disk. The kernel doesn't know if there is 
> an UUID embedded on the disk, and the kernel SHOULD NOT HAVE A POLICY to 
> try to find one.
> 
> But for user space, the thing is trivially done: the kernel will notify
> user space about the fact that it found a device (without necessarily
> knowing what the heck the device is - quite common with USB or specialty
> SCSI devices). The kernel pretty much doesn't know _anything_ about things
> like laser range finders, cameras etc. It ends up classifying the device 
> on a very rough level, nothing more.
> 
> And without knowing practically _anythign_ about the device, it still has
> to allocate a device number. Exactly so that somebody else can come around
> and poke at it, and maybe know that "ahh, this device is a USB-attached
> camera" or similar.
> 
> Do you not see that fundamental issue? The kernel has to allocate a number 
> before a UUID or anythign else is necessarily available. 
> 
> The UUID/serial number/type policy comes _later_.
> 
> 		Linus

Re: udev and devfs - The final word

[Mark Mielke]

On Mon, Jan 05, 2004 at 04:17:57PM -0600, Shawn wrote:
> Having said that, I will say that they are /somewhat/ stable. You can,
> in general, say 'fdisk /dev/hdb' and be editing the same block device's
> partition table... That is, if nothing has changed in the BIOS or
> hardware or kernel or....
> ...
> As an admin, would I at least theoretically have /some/ consistency if
> merely for my own sanity when dealing with block devices by hand (I do
> need to setup LVM stuff from time to time)??

If all you care about is that /dev names remain consistent, you need
not fear. udev and devfs are two different ways of providing this
consistency. They abstract the device numbers from the /dev names,
meaning that you don't have to care if the numbers change. The names
don't.

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 and devfs - The final word

[Shawn]

On Mon, 2004-01-05 at 16:25, Mark Mielke wrote:
> On Mon, Jan 05, 2004 at 04:17:57PM -0600, Shawn wrote:
> > ...
> > As an admin, would I at least theoretically have /some/ consistency if
> > merely for my own sanity when dealing with block devices by hand (I do
> > need to setup LVM stuff from time to time)??
> 
> If all you care about is that /dev names remain consistent, you need
> not fear. udev and devfs are two different ways of providing this
> consistency. They abstract the device numbers from the /dev names,
> meaning that you don't have to care if the numbers change. The names
> don't.
I'm obviously confused if this is true, as then I do not know how the
great and powerful udev derives the names if not from the numbers, or
some other sysfs info.

Anyway, assuming this is true, I have much less concern.

Re: udev and devfs - The final word

[Shawn]

And looking back on some of these emails, it seems there was more than
just me being confused. Seems this is a point worth emphasizing.

On Mon, 2004-01-05 at 17:05, Shawn wrote:
> On Mon, 2004-01-05 at 16:25, Mark Mielke wrote:
> > On Mon, Jan 05, 2004 at 04:17:57PM -0600, Shawn wrote:
> > > ...
> > > As an admin, would I at least theoretically have /some/ consistency if
> > > merely for my own sanity when dealing with block devices by hand (I do
> > > need to setup LVM stuff from time to time)??
> > 
> > If all you care about is that /dev names remain consistent, you need
> > not fear. udev and devfs are two different ways of providing this
> > consistency. They abstract the device numbers from the /dev names,
> > meaning that you don't have to care if the numbers change. The names
> > don't.
> I'm obviously confused if this is true, as then I do not know how the
> great and powerful udev derives the names if not from the numbers, or
> some other sysfs info.
> 
> Anyway, assuming this is true, I have much less concern.

Re: udev and devfs - The final word

[Greg KH]

On Mon, Jan 05, 2004 at 05:05:16PM -0600, Shawn wrote:
> On Mon, 2004-01-05 at 16:25, Mark Mielke wrote:
> > On Mon, Jan 05, 2004 at 04:17:57PM -0600, Shawn wrote:
> > > ...
> > > As an admin, would I at least theoretically have /some/ consistency if
> > > merely for my own sanity when dealing with block devices by hand (I do
> > > need to setup LVM stuff from time to time)??
> > 
> > If all you care about is that /dev names remain consistent, you need
> > not fear. udev and devfs are two different ways of providing this
> > consistency. They abstract the device numbers from the /dev names,
> > meaning that you don't have to care if the numbers change. The names
> > don't.
> I'm obviously confused if this is true, as then I do not know how the
> great and powerful udev derives the names if not from the numbers, or
> some other sysfs info.

udev can derive the names for the /dev entries from just about anything
you can think of:
	- sysfs files
	- bus topology
	- bus ids
	- any script/program that you might want to run
	- the kernel name

It will default back to the "kernel name" that shows up in sysfs, and is
what we currently use, if it can not match up any other name to it.  The
method of creating these rules that udev uses, are contained in the
udev.rules file.  See the udev man page for the syntax and some example
rules.  Also see the example udev.rules and udev.rules.devfs files for
lots more example rules that you might want to come up with.

The strength in this is that udev can poke around and try to find a
unique "tag" that a specific device exports (be it UUID, or a CDDB
entry) and use that to match up a name to.  That enables your cdrom to
always be called /dev/cdrom no matter where in the scsi chain it happens
to be.

In summary, udev doesn't care squat about the major/minor that the
kernel has used for a device.  It merely uses those numbers and creates
a /dev entry with them, assigned to a name that it comes up with.

Does that help out?  The udev OLS paper might also help explain some of
this.

thanks,

greg k-h

Re: udev and devfs - The final word

[Shawn]

I'm embarrassed to say I did not read that.

I'm starting to wonder what some folks are complaining about. WRT
practicality and useability, udev about covers it once alsa and vmware
;) get sysfs-ified.

My own foray into udev was a little lacking owing to these little
issues.

On Mon, 2004-01-05 at 18:43, Greg KH wrote:
> In summary, udev doesn't care squat about the major/minor that the
> kernel has used for a device.  It merely uses those numbers and creates
> a /dev entry with them, assigned to a name that it comes up with.
> 
> Does that help out?  The udev OLS paper might also help explain some of
> this.

Re: udev and devfs - The final word

[Andries Brouwer]

On Mon, Jan 05, 2004 at 12:38:54PM -0800, Linus Torvalds wrote:

> Have you even _tried_ udev?

Yes, and it works reasonably well. I have version 012 here.
Some flaws will be fixed in 013 or so. Some difficulties are of a
more fundamental type, not so easy to fix. But udev is an entirely
different discussion. Some other time.

> In particular, the kernel should never have policy encoded in it, and 
> naming of a device is about pretty much nothing _but_ policy.

Of course. But this is not about naming.

The kernel invents device numbers, and user space names.

Now compare our setups:

dev_t lbt_devno(void) { return random(); }

dev_t aeb_devno(char *s) { dev_t d = hash(s); while (inuse(d)) d++; return d; }

An earlier fragment of the discussion was concerned with the fact
that random(); is a bad idea. Something reproducible is better.

Let us abbreviate the above function f. Some driver determines that
a disk has serial number A809ADGC. Another driver determines that
some device was produced by HP but otherwise has no opinion.
A third driver has no stable information at all about the device.
They assign device numbers f("A809ADGC"), f("HP"), f("").

What is the result? Yes, device numbers are cookies, but a reasonable
attempt has been made to make the device numbers stable.
No guarantees anywhere - this is best effort. Better than no effort.

And this information helps udev. It may make a callout superfluous,
or even give udev information that cannot be obtained from userspace.

Andries

Re: udev and devfs - The final word

[Linus Torvalds]

On Tue, 6 Jan 2004, Andries Brouwer wrote:
> 
> Now compare our setups:
> 
> dev_t lbt_devno(void) { return random(); }

Actually, I'd have something like

	int nr;

	initialize()
	{
	#ifdef CONFIG_DEBUG_BAD_USERS
		nr = random();
	#endif
	}

	dev_t lbt_devno()
	{
		return nr++;
	}

since the numbers do have to be unique "per boot". They just shouldn't be 
considered "stable" _nor_ "meaningful".

> dev_t aeb_devno(char *s) { dev_t d = hash(s); while (inuse(d)) d++; return d; }
> 
> An earlier fragment of the discussion was concerned with the fact
> that random(); is a bad idea. Something reproducible is better.

And I've told you why reproducibility is a BAD THING, and why I disagree.

Basically, if you cannot 100% guarantee reproducibility (and nobody can,
not your hashes, not anything else), then the _appearance_ of 
reproducibility is literally a mistake. Because it ends up being a bug 
waiting to happen - and one that is very very hard to reproduce on a 
developer machine.

You seem to continually ignore this issue.

I'm  not going to bother arguign this for another week. I'm just going to 
state once and for all:

 - total device number reproducability is fundamentally impossible. It's 
   not just impossible in theory, it is impossible in practice too.
 - with that in mind, anything that depends on stable device numbers is a 
   BUG.
 - Thus all your arguments boil down to: "I want to encourage bugs".

My argument is that we should find and fix the bugs. And we should do so 
by making the lack of meaning of the device numbers as well-known as 
possible. And that shouldn't just be due to long and boring threads on the 
kernel mailing list, but by actually actively trying to trigger the bad 
cases.

Bugs are good at hiding, and then showing up at the most inopportune 
times when you can't debug them. It's much better to try to trigger them 
where a developer can see them, and you do that by doing strange things.

		Linus

Re: udev and devfs - The final word

[viro]

On Mon, Jan 05, 2004 at 03:32:03PM -0800, Linus Torvalds wrote:
> 	dev_t lbt_devno()
> 	{
> 		return nr++;
> 	}
> 
> since the numbers do have to be unique "per boot". They just shouldn't be 
> considered "stable" _nor_ "meaningful".

Cute.  There's a little issue of, say it, meaningful relationship between
sda and sda4, completely lost that way.  And _that_ has nothing to do with
device enumeration.

Re: udev and devfs - The final word

[Linus Torvalds]

On Tue, 6 Jan 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
> 
> Cute.  There's a little issue of, say it, meaningful relationship between
> sda and sda4, completely lost that way.  And _that_ has nothing to do with
> device enumeration.

Oh, don't look too closely at some pseudo-code, it's not like the code
would actually do that for a minor number. But for things like major
number allocation for disk devices, it might not be too far off. And we 
migth even want to start off the minors at some "random" offset (obviously 
while keeping the alignment right for the partition handling)

		Linus

Re: udev and devfs - The final word

[viro]

On Mon, Jan 05, 2004 at 05:17:20PM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 6 Jan 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
> > 
> > Cute.  There's a little issue of, say it, meaningful relationship between
> > sda and sda4, completely lost that way.  And _that_ has nothing to do with
> > device enumeration.
> 
> Oh, don't look too closely at some pseudo-code, it's not like the code
> would actually do that for a minor number. But for things like major
> number allocation for disk devices, it might not be too far off. And we 
> migth even want to start off the minors at some "random" offset (obviously 
> while keeping the alignment right for the partition handling)

True, but...  Let me put it that way - entire area is a minefield and
I would really like to avoid nasty surprises from "obvious" patches,
what with having just spent 4 months dealing with the fallout from one
such beast.

Let's clean the things up first; then it will be easier to see what can
and should be done.  Sure thing, reducing amount of places that deal with
device numbers is a good thing.  Let's see how far we can get it, what
obstacles still remain (and during 2.5 a _lot_ of them had been killed)
and what is needed to remove the rest.

Once they are gone (and that will be one-by-one, keeping the list of
things to grep for and checking the results of greps as we go) - then
we'll have cleaner playing field for any experiments in that area.
_And_ there will be less temptation to play the bundling games for
everyone involved (cf. devfs disaster, aka. "my glorious idea allows
to do $NEEDED_THING that way; merge the entire thing and nevermind
the fact that doing $NEEDED_THING essentially the same way is possible
without the rest of patch and can be split out of it").

Re: udev and devfs - The final word

[Linus Torvalds]

On Tue, 6 Jan 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
> > 
> > Oh, don't look too closely at some pseudo-code, it's not like the code
> > would actually do that for a minor number. But for things like major
> > number allocation for disk devices, it might not be too far off. And we 
> > migth even want to start off the minors at some "random" offset (obviously 
> > while keeping the alignment right for the partition handling)
> 
> True, but...  Let me put it that way - entire area is a minefield and
> I would really like to avoid nasty surprises from "obvious" patches,
> what with having just spent 4 months dealing with the fallout from one
> such beast.

Hey, it's entirely possible that we won't be able to do it at _all_ during 
2.7.x, since it would require that all the distributions have started 
using udev or equivalent. Which is by no means certain at all. It's 
possible that just lack of ubiqutous infrastructure will mean that it 
would be too painful to even try this in a few months..

Do don't worry too much.

		Linus

Re: udev and devfs - The final word

[Andries Brouwer]

On Mon, Jan 05, 2004 at 03:32:03PM -0800, Linus Torvalds wrote:

> > Something reproducible is better.
> 
> And I've told you why reproducibility is a BAD THING
> 
> Basically, if you cannot 100% guarantee reproducibility,
> then the _appearance_ of reproducibility is literally a mistake.

OK. We now understand perfectly each others point of view.
It was a pleasure to provoke this discussion - can hardly
wait for 2.7 :-)

Andries

Re: udev and devfs - The final word

[Mark Mielke]

On Tue, Jan 06, 2004 at 02:06:48AM +0100, Andries Brouwer wrote:
> On Mon, Jan 05, 2004 at 03:32:03PM -0800, Linus Torvalds wrote:
> > > Something reproducible is better.
> > And I've told you why reproducibility is a BAD THING
> > Basically, if you cannot 100% guarantee reproducibility,
> > then the _appearance_ of reproducibility is literally a mistake.
> OK. We now understand perfectly each others point of view.
> It was a pleasure to provoke this discussion - can hardly
> wait for 2.7 :-)

Hehe.... s/provoke/perpetuate/g

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 and devfs - The final word

[Greg KH]

On Tue, Jan 06, 2004 at 12:13:26AM +0100, Andries Brouwer wrote:
> On Mon, Jan 05, 2004 at 12:38:54PM -0800, Linus Torvalds wrote:
> 
> > Have you even _tried_ udev?
> 
> Yes, and it works reasonably well. I have version 012 here.
> Some flaws will be fixed in 013 or so.

What flaws would that be?  The short time delay for partitions?  Or
something else?

> Some difficulties are of a more fundamental type, not so easy to fix.

Such as?

> But udev is an entirely different discussion. Some other time.

Feel free to bring it up on the linux-hotplug-devel list whenever you
wish.

thanks,

greg k-h

Re: udev and devfs - The final word

[Andries Brouwer]

On Mon, Jan 05, 2004 at 04:00:15PM -0800, Greg KH wrote:

> > > Have you even _tried_ udev?
> > 
> > Yes, and it works reasonably well. I have version 012 here.
> > Some flaws will be fixed in 013 or so.
> 
> What flaws would that be?  The short time delay for partitions?  Or
> something else?

Yes, partitions are not handled very well.
So far I have never seen udev discover partitions on its own.
I provoke it using "blockdev --rereadpt".
The result is that partitions appear in /proc/partitions and in /udev.
After removing the media another "blockdev --rereadpt" returns
"No such device or address" and the entry in /proc/partitions
disappears, but that in /udev stays.

> > Some difficulties are of a more fundamental type, not so easy to fix.
> 
> Such as?

Udev cannot do anything when there are no events.
And media insertion or removal does not always give events.

Andries

[By the way, a compilation warning for every C file:
% make
gcc  -pipe -Wall -Wmore.. -Os -fomit-frame-pointer -D_GNU_SOURCE \
  -I/usr/lib/gcc-lib/i486-suse-linux/3.2/include -I.../udev-012/libsysfs
  -c -o udev.o udev.c
cc1: warning: changing search order for system directory
     "/usr/lib/gcc-lib/i486-suse-linux/3.2/include"
cc1: warning: as it has already been specified as a non-system directory]

Re: udev and devfs - The final word

[Greg KH]

On Tue, Jan 06, 2004 at 02:41:15AM +0100, Andries Brouwer wrote:
> On Mon, Jan 05, 2004 at 04:00:15PM -0800, Greg KH wrote:
> 
> > > > Have you even _tried_ udev?
> > > 
> > > Yes, and it works reasonably well. I have version 012 here.
> > > Some flaws will be fixed in 013 or so.
> > 
> > What flaws would that be?  The short time delay for partitions?  Or
> > something else?
> 
> Yes, partitions are not handled very well.
> So far I have never seen udev discover partitions on its own.

That is because it can not.  Please see the current thread "removable
media revalidation - udev vs. devfs or static /dev" on lkml for a
solution to this.

> > > Some difficulties are of a more fundamental type, not so easy to fix.
> > 
> > Such as?
> 
> Udev cannot do anything when there are no events.
> And media insertion or removal does not always give events.

Exactly.  That's why userspace needs to poll for this.

> [By the way, a compilation warning for every C file:
> % make
> gcc  -pipe -Wall -Wmore.. -Os -fomit-frame-pointer -D_GNU_SOURCE \
>   -I/usr/lib/gcc-lib/i486-suse-linux/3.2/include -I.../udev-012/libsysfs
>   -c -o udev.o udev.c
> cc1: warning: changing search order for system directory
>      "/usr/lib/gcc-lib/i486-suse-linux/3.2/include"
> cc1: warning: as it has already been specified as a non-system directory]

Odd, it works here just fine on a number of different Red Hat boxes :)

thanks,

greg k-h

Re: udev and devfs - The final word

[Rob Landley]

On Monday 05 January 2004 17:13, Andries Brouwer wrote:
> An earlier fragment of the discussion was concerned with the fact
> that random(); is a bad idea. Something reproducible is better.

To find people making bad assuptions that will only break after widespread 
deployment, random() is much better than "usually reproducible".

> Let us abbreviate the above function f. Some driver determines that
> a disk has serial number A809ADGC. Another driver determines that
> some device was produced by HP but otherwise has no opinion.
> A third driver has no stable information at all about the device.
> They assign device numbers f("A809ADGC"), f("HP"), f("").
>
> What is the result? Yes, device numbers are cookies, but a reasonable
> attempt has been made to make the device numbers stable.

Should the same argument be made about process ID's?  When your system boots 
up, your daemons generally start in the same order.  But any script that 
depends on this is broken.

Or filehandles.  They're cookies.  There's whole pages on why it's a bad idea 
to make assumptions about what filehandles point to:

http://en.tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-race.html

> No guarantees anywhere - this is best effort. Better than no effort.

You're suggesting that it should be easier to write things that are 
fundamentally unclean, and bake in assumptions that WILL break, but not on 
the developer's machine, only for end-users who aren't expecting it.

What's the advantage?  Making it easier for people to do something stupid?  
(You can sort of trust this thing we can't make any guarantees about.  Since 
when is "sort of trust" a condition that's encouraged?  At the very least, 
those kinds of cases are backed up by a detection and recovery mechanism and 
the whole thing's called a heuristic.)  Why is there a need for this?

Either the kernel can make a guarantee, or it should very much not make a 
guarantee.  Where is an example of a middle ground?

> And this information helps udev. It may make a callout superfluous,
> or even give udev information that cannot be obtained from userspace.

I'm waiting for the udev maintainer to weight in on this and say "no, it 
doesn't".  If there is information that "cannot be obtained from userspace", 
then we should fix the sysfs exports.  Encoding something in a semi-stable 
cookie and actually trying to USE that information is stupid.

What about kernel upgrades?  Future backwards compatability when developers 
change the device enumeration methods?  (The sata driver got completely 
rewritten from scratch, and now it detects devices in a wildly different 
order, but we need this shim layer for backwards compatability with a 
guarantee we never should have made because we encouraged old scripts to 
remain broken.)  This plants hidden land mines restricting future 
development.  You're basically proposing a whole "device number stabilization 
infrastructure" for future kernels if it's to have ANY meaning at all...

Where's the advantage?  Name a single real-world case that's more difficult to 
fix than it would be to make the kernel pander to it in perpetuity.

> Andries

Rob

Re: udev and devfs - The final word

[Vojtech Pavlik]

On Mon, Jan 05, 2004 at 08:52:28PM +0100, Andries Brouwer wrote:

> > udev can then use those serial numbers to have a stable pathname
> 
> True. Provided that it knows how to get them.
> The kernel driver knew all about the device.
> Must udev also know all about all possible devices?

No. But it must have rules about what to do with all possible device
types (at least very generic default rules), based on the data the
drivers can provide to identify the device.

> Do I/O to these devices?

If the using an UUID stored on the device (like the filesystem UUID), yes.

> Or must sysfs export all data that could possibly be used?

Not necessarily. But udev must get the all the data that could possibly
be used for assigning a name to the device. It can get them either as
hotplug command line arguments and environment variables or via sysfs,
or by any other means.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Silly udev script [was Re: udev and devfs - The final word]

[Greg KH]

On Mon, Jan 05, 2004 at 08:13:26AM -0800, Linus Torvalds wrote:
> 
> For example, if you wanted to, you could make udev do a cddb lookup on the
> CD-ROM, and use that as the pathname, so that when you insert your
> favorite audio disk, it will always show up in the same place, regardless 
> of whether you put it in the DVD slot or the CD-RW drive. 
> 
> [ Yeah, that sounds like a singularly silly thing to do, but it's a good 
>   example of something where there is no actual serial number, but you can 
>   "identify" it automatically through its contents, and name it stably 
>   according to that. ]

That was such a silly thing to do, here's a script that does it, along
with the udev rule to add to udev.rules for it.  It names your cdrom
Artist_Title, and creates a symlink called cdrom that points to it, just
to be a tiny bit sane :)

I had been saying for a long time that you could have udev make a query
across the network to get a device name, this provides the perfect
example of just that...

thanks,

greg k-h


#!/usr/bin/perl

# a horribly funny script that shows how flexible udev can really be
# This is to be executed by udev with the following rules:
# CALLOUT, BUS="ide", PROGRAM="name_cdrom.pl %M %m", ID="good*", NAME="%1c", SYMLINK="cdrom" 
# CALLOUT, BUS="scsi", PROGRAM="name_cdrom.pl %M %m", ID="good*", NAME="%1c", SYMLINK="cdrom" 
#
# The scsi rule catches USB cdroms and ide-scsi devices.
#

use CDDB_get qw( get_cddb );

my %config;

$dev_node = "/tmp/cd_foo";

# following variables just need to be declared if different from defaults
$config{CDDB_HOST}="freedb.freedb.org";        # set cddb host
$config{CDDB_PORT}=8880;                       # set cddb port
$config{CDDB_MODE}="cddb";			# set cddb mode: cddb or http
$config{CD_DEVICE}="$dev_node";			# set cd device

# No user interaction, this is a automated script!
$config{input}=0;

$major = $ARGV[0];
$minor = $ARGV[1];

# create our temp device node to read the cd info from
if (system("mknod $dev_node b $major $minor")) {
       die "bad mknod failed";
       }

# get it on
my %cd=get_cddb(\%config);

# remove the dev node we just created
unlink($dev_node);

# print out our cd name if we have found it
unless(defined $cd{title}) {
	print"bad unknown cdrom\n";
} else {
	print "good $cd{artist}_$cd{title}\n";
}

Re: udev and devfs - The final word

[James H. Cloos Jr.]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:

Linus> Why? Becuase that _program_ sure as hell isn't
Linus> running across a reboot.

Is that strictly true?  With (software) suspend to disk,
will the old device enumeration data be recovered from
the suspend partition?

-JimC

Re: udev and devfs - The final word

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Hi.

On Mon, 2004-01-05 at 20:44, James H. Cloos Jr. wrote:
> >>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
> 
> Linus> Why? Becuase that _program_ sure as hell isn't
> Linus> running across a reboot.
> 
> Is that strictly true?  With (software) suspend to disk,
> will the old device enumeration data be recovered from
> the suspend partition?

Yes. You end up running the original kernel.

Regards,

Nigel

-- 
My work on Software Suspend is graciously brought to you by
LinuxFund.org.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: udev and devfs - The final word

[Robin Rosenberg]

måndagen den 5 januari 2004 08.45 skrev Nigel Cunningham:
> Hi.
>
> On Mon, 2004-01-05 at 20:44, James H. Cloos Jr. wrote:
> > >>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
> >
> > Linus> Why? Becuase that _program_ sure as hell isn't
> > Linus> running across a reboot.
> >
> > Is that strictly true?  With (software) suspend to disk,
> > will the old device enumeration data be recovered from
> > the suspend partition?
>
> Yes. You end up running the original kernel.

But not necessarily the same devices.

> Regards,
>
> Nigel

-- rob in

Re: udev and devfs - The final word

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

Hi.

The suspend to disk implementations all assume that devices are not
[dis]appearing under us while we're suspended. If you do go adding and
removing devices while the power is off, you can expect the same
problems you'd get if you removed them without suspending the machine.
It would be roughly equivalent to hot[un]plugging devices.

To return to the original point though, userspace may see a sudden big
jump in the time clock if it's looking, but it won't suddenly find major
& minor numbers are different.

Regards,

Nigel

On Tue, 2004-01-06 at 00:01, Robin Rosenberg wrote:
> > Yes. You end up running the original kernel.
> 
> But not necessarily the same devices.

-- 
My work on Software Suspend is graciously brought to you by
LinuxFund.org.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

IRQ disabled on linux 2.6.1-rc1-mm1

[Mainak Mandal _00007001_]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4850 bytes --]

Hi,
I am running 2.6.1-rc1-mm1 on a suse 9.0 system.
But i am having problems with the sound drivers/alsa.
I have compiled the sound drivers into the kernel and not as a loadable 
module, but the sound system fails to start automatically after a reboot.
I have to go into yast and go thru the sound setup everytime i boot and 
the strange thing is that the sound card is already configured and shows 
that it is running. I just have to go thru it and sound starts working.
however sometimes after a little while the message
disabling IRQ #11 
appears and the sound card stops working. 

and everytime I boot the kernel also disables IRQ #9.

the following lines are from the o/p of the hwinfo command.

17: PCI 0d.0: 0200 Ethernet controller
  [Created at pci.65]
  Unique ID: qnJ_.zq4WwPe20r5
  Hardware Class: network
  Model: "Davicom Ethernet 100/10 MBit"
  Vendor: pci 0x1282 "Davicom Semiconductor, Inc."
  Device: pci 0x9102 "Ethernet 100/10 MBit"
  SubVendor: pci 0x0291
  SubDevice: pci 0x8212
  Revision: 0x31
  I/O Ports: 0xdc00-0xdcff (rw)
  Memory Range: 0xdfffff00-??? (rw,non-prefetchable)
  Memory Range: 0xdff80000-??? (ro,disabled)
  IRQ: 17 (1955378 events)
  Driver Info #0:
    Driver Status: dmfe is not active
    Driver Activation Cmd: "insmod dmfe"
  Driver Info #1:
    Driver Status: tulip is not active
    Driver Activation Cmd: "insmod tulip"
  Config Status: cfg=yes, avail=yes, need=no, active=unknown

23: PCI 11.5: 0401 Multimedia audio controller
  [Created at pci.65]
  Unique ID: Ssy1.FSRBkG45L8D
  Hardware Class: sound
  Model: "Giga-byte GA-7VAX Onboard Audio (Realtek ALC650)"
  Vendor: pci 0x1106 "VIA Technologies, Inc."
  Device: pci 0x3059 "VT8233/A/8235 AC97 Audio Controller"
  SubVendor: pci 0x1458 "Giga-byte Technology"
  SubDevice: pci 0xa002 "GA-7VAX Onboard Audio (Realtek ALC650)"
  Revision: 0x30
  I/O Ports: 0xd800-0xd8ff (rw)
  IRQ: 11 (2000000 events)
  Driver Info #0:
    Driver Info: snd-via686,snd-via8233
  Config Status: cfg=yes, avail=yes, need=no, active=unknown

41: PCI 11.5: 0401 Multimedia audio controller
  [Created at manual.260]
  Unique ID: Ssy1.V2mM3CHvMND
  Hardware Class: sound
  Model: "VIA VT8233/A/8235 AC97 Audio Controller"
  Vendor: pci 0x1106 "VIA Technologies, Inc."
  Device: pci 0x3059 "VT8233/A/8235 AC97 Audio Controller"
  Revision: 0x30
  I/O Ports: 0xd800-0xd8ff (rw)
  IRQ: 11 (10290 events)
  Driver Info #0:
    Driver Info: snd-via686,snd-via8233
  Config Status: cfg=no, avail=no, need=no, active=unknown

44: PCI 0c.0: 0200 Ethernet controller
  [Created at manual.260]
  Unique ID: lgGW.zq4WwPe20r5
  Hardware Class: network
  Model: "Davicom Ethernet 100/10 MBit"
  Vendor: pci 0x1282 "Davicom Semiconductor, Inc."
  Device: pci 0x9102 "Ethernet 100/10 MBit"
  SubVendor: pci 0x0291
  SubDevice: pci 0x8212
  Revision: 0x31
  I/O Ports: 0xdc00-0xdcff (rw)
  Memory Range: 0xdfffff00-??? (rw,non-prefetchable)
  Memory Range: 0xdff80000-??? (ro,disabled)
  IRQ: 11 (1282 events)
  Driver Info #0:
    Driver Status: dmfe is not active
    Driver Activation Cmd: "insmod dmfe"
  Driver Info #1:
    Driver Status: tulip is not active
    Driver Activation Cmd: "insmod tulip"
  Config Status: cfg=yes, avail=no, need=no, active=unknown

55: PCI 11.6: 0780 Communication controller
  [Created at manual.260]
  Unique ID: KBSt.m2OuY_layX5
  Hardware Class: unknown
  Model: "VIA Intel 537 [AC97 Modem]"
  Vendor: pci 0x1106 "VIA Technologies, Inc."
  Device: pci 0x3068 "Intel 537 [AC97 Modem]"
  Revision: 0x70
  I/O Ports: 0xd800-0xd8ff (rw)
  IRQ: 9 (no events)
  Config Status: cfg=new, avail=no, need=no, active=unknown

If you need any more information then plz to follow up and is there any 
way of enabling an IRQ.

also although it shows IRQ #11 disabled network continues to work.

I have also attached the .config file for my system

Mainak Mandal

-- 
----------------------------------------------------------------------------------------------------
		"Choose life. Choose a job. Choose a career. Choose a family. Choose a big fucking
		 television, choose washing machines, cars, compact disk players and electrical tin 
		openers...choose DIY and wondering who the fuck you are on a Sunday morning. Choose sitting
		 on the couch, watching mind-numbing, spirit-crushing game shows, stuffing junk food
		 into your mouth. Choose rotting away at the end of it all, pishing your last in a 
		miserable home, nothing more than an embarassment to the selfish, fucked-up brats you 
		spawned to replace yourself. Choose your future. Choose life. But why would I want to do a
		 thing lke that? I chose not to choose life. I chose something else. And the reasons? 
			There are no reasons. Who needs reasons when you've got heroin?"	
					
					--Irvine Welsh
  	  				  TRAINSPOTTING (1996)

We are the people our parents warned us about...

[-- Attachment #2: Type: TEXT/PLAIN, Size: 26601 bytes --]

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
# CONFIG_STANDALONE is not set
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# 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_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# 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_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
# CONFIG_X86_4G is not set
# CONFIG_X86_SWITCH_PAGETABLES is not set
# CONFIG_X86_4G_VM_LAYOUT is not set
# CONFIG_X86_UACCESS_INDIRECT is not set
# CONFIG_X86_HIGH_ENTRY is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_DISK=y
CONFIG_PM_DISK_PARTITION=""

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_RELAXED_AML is not set
# CONFIG_X86_PM_TIMER is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
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_PCI_USE_VECTOR is not set
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
CONFIG_EISA=y
# CONFIG_EISA_VLB_PRIMING is not set
CONFIG_EISA_PCI_EISA=y
CONFIG_EISA_VIRTUAL_ROOT=y
CONFIG_EISA_NAMES=y
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_HOTPLUG is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m

#
# Device Drivers
#

#
# Generic Driver Options
#

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=64000
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_IDE_TASK_IOCTL=y
CONFIG_IDE_TASKFILE_IO=y

#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX 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_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_SCSI is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_PCI=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_PROC=m

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
# 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=y
# CONFIG_SYN_COOKIES is not set
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_IPV6_TUNNEL=y
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
# CONFIG_IP_NF_IRC is not set
CONFIG_IP_NF_TFTP=y
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
# CONFIG_IP_NF_MATCH_IPRANGE is not set
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
# CONFIG_IP_NF_MATCH_RECENT is not set
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_IP_NF_TARGET_SAME is not set
# CONFIG_IP_NF_NAT_LOCAL is not set
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
# CONFIG_IP_NF_TARGET_CLASSIFY is not set
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
# CONFIG_IP_NF_ARP_MANGLE is not set

#
# IPv6: Netfilter Configuration
#
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
CONFIG_XFRM=y
# CONFIG_XFRM_USER 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_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB 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=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
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_MII=y
# CONFIG_HAPPYMEAL 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

#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
CONFIG_DM9102=y
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI 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_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# 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_RCPCI is not set
CONFIG_SHAPER=m
CONFIG_NETCONSOLE=m

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# Bluetooth support
#
# CONFIG_BT is not set
# CONFIG_KGDBOE is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
# CONFIG_I2C_ELV is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_ISA is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VELLEMAN is not set
# CONFIG_I2C_VIA is not set
CONFIG_I2C_VIAPRO=y
# CONFIG_I2C_VOODOO3 is not set

#
# I2C Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=y
# CONFIG_SENSORS_ADM1021 is not set
CONFIG_SENSORS_EEPROM=y
CONFIG_SENSORS_IT87=m
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_PANIC_EVENT=y
# CONFIG_IPMI_PANIC_STRING is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_KCS=m
CONFIG_IPMI_WATCHDOG=m

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
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=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=256
# CONFIG_HANGCHECK_TIMER is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
CONFIG_FB=y
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set

#
# Logo configuration
#
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_VERBOSE_PRINTK=y
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_SONICVIBES is not set
CONFIG_SND_VIA82XX=y
# CONFIG_SND_VX222 is not set

#
# ALSA USB devices
#
# CONFIG_SND_USB_AUDIO is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

#
# SCSI support is needed for USB Storage
#
# CONFIG_USB_STORAGE is not set

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV 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_XPAD is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network adaptors
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_BRLVGER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GADGET is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=m
CONFIG_UDF_FS=m

#
# DOS/FAT/NT Filesystems
#
# CONFIG_FAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_GSS is not set
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_SELINUX is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=m
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

Re: udev and devfs - The final word

[Robin Rosenberg]

måndagen den 5 januari 2004 13.39 skrev Nigel Cunningham:
> Hi.
>
> The suspend to disk implementations all assume that devices are not
> [dis]appearing under us while we're suspended. If you do go adding and
> removing devices while the power is off, you can expect the same
> problems you'd get if you removed them without suspending the machine.
> It would be roughly equivalent to hot[un]plugging devices.

Yes. It's very unclear unless you do mind reading, but I had in mind mounted filesystems
such as /home on a USB stick or firewire Reasonable? yes! But such devices have to
be rediscovered and allocated in such a way that the user can resume using the device
as soon as it has been found. And it should not fail miserably if the user forgets to connect
the device before resuming the machine. As you cannot unmount /home (usually) the
kernel must remember the device somehow or make mounting file systems more loosely
than today.

-- robin

Re: udev and devfs - The final word

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

Ah. Well if you've unmounted filesystems prior to suspending, I would
expect you should be fine. The device numbers might change - if they can
change between mounts - but that won't be any different because of
suspending. If you're talking about suspending with the file systems
mounted, that ought to work to (once the appropriate power management
support is done). If the user fails to reconnect the device before
resuming, they should expect the same problems that they would encounter
if they pulled it out without suspending. Of course I'm saying 'should'
a lot here. Let me use it one more time... in my mind at least, the fact
that we've suspended should be irrelevant to how things work.

Regards,

Nigel

On Thu, 2004-01-08 at 02:39, Robin Rosenberg wrote:
> måndagen den 5 januari 2004 13.39 skrev Nigel Cunningham:
> > Hi.
> >
> > The suspend to disk implementations all assume that devices are not
> > [dis]appearing under us while we're suspended. If you do go adding and
> > removing devices while the power is off, you can expect the same
> > problems you'd get if you removed them without suspending the machine.
> > It would be roughly equivalent to hot[un]plugging devices.
> 
> Yes. It's very unclear unless you do mind reading, but I had in mind mounted filesystems
> such as /home on a USB stick or firewire Reasonable? yes! But such devices have to
> be rediscovered and allocated in such a way that the user can resume using the device
> as soon as it has been found. And it should not fail miserably if the user forgets to connect
> the device before resuming the machine. As you cannot unmount /home (usually) the
> kernel must remember the device somehow or make mounting file systems more loosely
> than today.
> 
> -- robin
-- 
My work on Software Suspend is graciously brought to you by
LinuxFund.org.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: udev and devfs - The final word

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

On Mon, 05 Jan 2004 02:44:10 EST, "James H. Cloos Jr." said:
> >>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
> 
> Linus> Why? Becuase that _program_ sure as hell isn't
> Linus> running across a reboot.
> 
> Is that strictly true?  With (software) suspend to disk,
> will the old device enumeration data be recovered from
> the suspend partition?

That would be a suspend, not a reboot, if we're speaking strictly....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: udev and devfs - The final word

[Peter Chubb]

>>>>> "Andries" == Andries Brouwer <aebr@win.tue.nl> writes:

Andries> On Sun, Jan 04, 2004 at 01:05:20PM -0800, Linus Torvalds
Andries> wrote:

Andries> Surprise! Are you leaving POSIX? Or ditching NFS?  Or
Andries> demanding that NFS servers must never reboot?

Andries> A common Unix idiom is testing for the identity of two files
Andries> by comparing st_ino and st_dev.  A broken idiom?

It's worse than that.  You can do
     mknod fred b maj minor
anywhere on any UNIX filesystem and expect it to a) work and b) refer
to the same device for all time until it is removed. However, this
doesn't appear to be guaranteed by SUS -- the only guarantees are that
the dev_t returned from the stat() family of calls is unique within a LAN.

I know that Linux already breaks this (the stupid /dev/sg[0-9] that
depend not on the SCSI bus and lun but on the order they're detected,
for example) 

Re: udev and devfs - The final word

[Linus Torvalds]

On Mon, 5 Jan 2004, Peter Chubb wrote:
> 
> It's worse than that.  You can do
>      mknod fred b maj minor
> anywhere on any UNIX filesystem and expect it to a) work and b) refer
> to the same device for all time until it is removed.

Hmm.. I can see (a) (except for the fact that pretty  much all unixes have 
mount-flags to say "no device files") but I don't see why you'd _ever_ 
expect (b) to be true.

It's patently not true for such rather traditional unix devices as pty's, 
for example. The "same device" ends up being true only for as long as the 
master at the other end exists - and the same numbers get re-used in all 
normal usage for different virtual devices.

> I know that Linux already breaks this (the stupid /dev/sg[0-9] that
> depend not on the SCSI bus and lun but on the order they're detected,
> for example) 

That "stupid" thing is a hell of a lot less stupid than the alternatives, 
and is very much equivalent to how pty's work. 

In fact, the "number according to detection" is pretty much the best 
device number allocation strategy. It's the _only_ one that doesn't have 
some incorrect bias built-in. 

			Linus

Wrapping jiffies [was Re: udev and devfs - The final word]

[Pavel Machek]

Hi!

> actively do things that are "silly" on purpose. For example, for 
> debugging, we start the "jiffies" counter not at zero, but at -300. That's 
> patently _silly_, but it was very useful in finding the cases where the 
> rare general case was not handled correctly.

BTW, as we are currently in stable series, it might be good idea to
make jiffies start at zero... Hopefully jiffie wrap had enough testing
during stable...

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: udev and devfs - The final word

[Kai Henningsen]

rob@landley.net (Rob Landley)  wrote on 01.01.04 in <200401010634.28559.rob@landley.net>:

> On Wednesday 31 December 2003 18:31, Rob Love wrote:
> > On Wed, 2003-12-31 at 19:15, Andries Brouwer wrote:
> > > My plan has been to essentially use a hashed disk serial number
> > > for this "any old unique value". The problem is that "any old"
> > > is easy enough, but "unique" is more difficult.
> > > Naming devices is very difficult, but in some important cases,
> > > like SCSI or IDE disks, that would work and give a stable name.
> >
> > Yup.
> >
> > > The kernel must not invent consecutive numbers - that does not
> > > lead to stable names. Setting this up correctly is nontrivial.
> >
> > This is definitely an interesting problem space.
> >
> > I agree wrt just inventing consecutive numbers.  If there was a nice way
> > to trivially generate a random and unique number from some
> > device-inherent information, that would be nice.
> >
> > 	Rob Love
>
> Fundamental problem: "Unique" depends on the other devices in the system.
> You can't guarantee unique by looking at one device, more or less by
> definition.

This is actually not fundamental at all.

The best-known exception is probably the MAC address. But it is not the  
only example of devices having true unique information.

It is certainly true, though, that there are devices without this kind of  
info.

And remember that you can sometimes use secondary information. With any  
kind of read-write storage device, it might be possible to create such a  
piece of information and store it onto that device.

Moral: keep the identifier creation framework flexible enough so that you  
can chose device-specific means to produce useful identifiers. (And, use  
long identifiers, as they're less likely to be duplicated in general.)

MfG Kai

Re: udev and devfs - The final word

[Rob Landley]

On Thursday 01 January 2004 13:43, Kai Henningsen wrote:
> rob@landley.net (Rob Landley)  wrote on 01.01.04 in 
<200401010634.28559.rob@landley.net>:
> > On Wednesday 31 December 2003 18:31, Rob Love wrote:
> > > On Wed, 2003-12-31 at 19:15, Andries Brouwer wrote:
> > > > My plan has been to essentially use a hashed disk serial number
> > > > for this "any old unique value". The problem is that "any old"
> > > > is easy enough, but "unique" is more difficult.
> > > > Naming devices is very difficult, but in some important cases,
> > > > like SCSI or IDE disks, that would work and give a stable name.
> > >
> > > Yup.
> > >
> > > > The kernel must not invent consecutive numbers - that does not
> > > > lead to stable names. Setting this up correctly is nontrivial.
> > >
> > > This is definitely an interesting problem space.
> > >
> > > I agree wrt just inventing consecutive numbers.  If there was a nice
> > > way to trivially generate a random and unique number from some
> > > device-inherent information, that would be nice.
> > >
> > > 	Rob Love
> >
> > Fundamental problem: "Unique" depends on the other devices in the system.
> > You can't guarantee unique by looking at one device, more or less by
> > definition.
>
> This is actually not fundamental at all.
>
> The best-known exception is probably the MAC address. But it is not the
> only example of devices having true unique information.

I thought of mentioning this, but deleted it as a digression.  But since you 
brought it up:

A) There are ethernet cards that have the same mac address.  (Over the years, 
the cheap manufacturers have managed to screw this up.  Ask Alan Cox.)  They 
show up randomly and cause real headaches for network administrators if you 
don't think to look for it.

B) You can override the mac address thing thing comes with.  This is done all 
the time.  (Hot failover comes to mind, but it's not the only one.  I 
remember how the cable modem company that serviced my mother's house snagged 
the mac address of the cable modem as part of the inital setup, and refused 
to work with a different mac address.  (I asked their support guys: They 
wanted to make sure you were still using the machine they'd installed their 
special software on, which was a windows machine and I was installing a linux 
firewall.  And predicting THIS digression: yes I power cycled and hit the 
reset button on the cable modem, it didn't help.  The problem was at the 
other end, their gateway dropped packets from the wrong mac address.)

So I changed the mac address of the other machine as part of its init scripts, 
and it worked again...

> It is certainly true, though, that there are devices without this kind of
> info.
>
> And remember that you can sometimes use secondary information. With any
> kind of read-write storage device, it might be possible to create such a
> piece of information and store it onto that device.

I.E. a udev config entry?

> Moral: keep the identifier creation framework flexible enough so that you
> can chose device-specific means to produce useful identifiers. (And, use
> long identifiers, as they're less likely to be duplicated in general.)

Seems to be what udev is for.  When we do go to random major and minor 
numbers, maybe it would be useful to let udev request specific ones?  (Just a 
thought...)

> MfG Kai

Rob

Re: udev and devfs - The final word

[Greg KH]

On Fri, Jan 02, 2004 at 01:26:44AM -0600, Rob Landley wrote:
> > Moral: keep the identifier creation framework flexible enough so that you
> > can chose device-specific means to produce useful identifiers. (And, use
> > long identifiers, as they're less likely to be duplicated in general.)
> 
> Seems to be what udev is for.  When we do go to random major and minor 
> numbers, maybe it would be useful to let udev request specific ones?  (Just a 
> thought...)

Let udev request specific what?  Major/minor numbers?  Huh?  I think you
are very confused here...

thanks,

greg k-h

Re: udev and devfs - The final word

[Rob Landley]

On Sunday 04 January 2004 02:57, Greg KH wrote:
> On Fri, Jan 02, 2004 at 01:26:44AM -0600, Rob Landley wrote:
> > > Moral: keep the identifier creation framework flexible enough so that
> > > you can chose device-specific means to produce useful identifiers.
> > > (And, use long identifiers, as they're less likely to be duplicated in
> > > general.)
> >
> > Seems to be what udev is for.  When we do go to random major and minor
> > numbers, maybe it would be useful to let udev request specific ones? 
> > (Just a thought...)
>
> Let udev request specific what?  Major/minor numbers?  Huh?  I think you
> are very confused here...

Currently, NFS exports are using device major/minor as part of the identifier 
for an exported direcory, and device numbers are going to be dynamically 
allocated in 2.7 to support hotplug, so i was wondering if there was a need 
to have some way for root to go "I know this device hotplugged in at major 3 
minor 99, but if major 53 minor 12 is free, could you change it to that?")  A 
bit like dup2, only for devices.

The discussion has moved on since then, and now it seems pretty clear that NFS 
is going to be expected to use something OTHER than device numbers, and Linus 
wants a clean break with device nodes being cookies.  Better solution all 
around, really...

But the original question did make sense.  (The answer was "no", but that's 
often the sign of a good question. :)

> thanks,
>
> greg k-h

Rob

Re: udev and devfs - The final word

[Maciej Zenczykowski]

> Solve 90% of the problem space and have a human deal with the exceptions.
> How big's the unique number being exported, anyway?  (If it's 32 bits, the 
> exceptions are 1 in 4 billion.  It may never be seen in the wild...)

Wouldn't this be a classical birthday problem with 50% collision chance
popping up in and around a few hundred devices? [20 for 8 bits, 23 for
365, 302 for 16 bits, 77163 for 32 bits], and that's only in a single
system - with hundreds of thousands of systems even a 0.1% collision rate
is deadly. [0.1% collision rate at 32 bits with 2932 devices]  Even with 
only 300 devices per system, you'll still get a collision (at 32 bits) on 
more than 1 system in a hundred thousand.

Cheers,
MaZe.

Re: udev and devfs - The final word

[Greg KH]

On Fri, Jan 02, 2004 at 05:31:04AM -0500, Mark Mielke wrote:
> On Fri, Jan 02, 2004 at 01:17:20AM +0100, Maciej Zenczykowski wrote:
> > Wouldn't this be a classical birthday problem with 50% collision chance
> > popping up in and around a few hundred devices? [20 for 8 bits, 23 for
> > 365, 302 for 16 bits, 77163 for 32 bits], and that's only in a single
> > system - with hundreds of thousands of systems even a 0.1% collision rate
> > is deadly. [0.1% collision rate at 32 bits with 2932 devices]  Even with 
> > only 300 devices per system, you'll still get a collision (at 32 bits) on 
> > more than 1 system in a hundred thousand.
> 
> I don't see this (multiple systems) as relevant. Device numbers do not need
> to be unique across systems, and they shouldn't even need to be unique across
> system reboots. Even when collisions occur, it doesn't matter, as it can just
> pick a different random number, or follow a free list, or hundreds of other
> algorithms.
> 
> Isn't this all just a question of device registration performance? 1) The
> device module needs to register the appropriate numbers efficiently.

What is "efficiently"?  No one really cares about milliseconds here,
seconds are even tollerable at least for small seconds :)

> 2) /dev needs to be populated or updated efficiently. devfs tried for
> a just in time approach, whereas udev tries for a proactive approach.

"proactive"?  udev is "reactive" in that it reacts to the number that
the kernel exports to userspace.  That's all.

Remember, devfs also uses those same, hardcoded numbers...

thanks,

greg k-h

Re: udev and devfs - The final word

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On Fri, 02 Jan 2004 22:07:48 PST, Greg KH <greg@kroah.com>  said:

> What is "efficiently"?  No one really cares about milliseconds here,
> seconds are even tollerable at least for small seconds :)

Anybody who's had to sit and watch a Sun E10K enumerate 400+ disks
will disagree with that, unless "small seconds" are tiny fractions thereof. :)



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: udev and devfs - The final word

[Ian Kent]

On Sat, 3 Jan 2004 Valdis.Kletnieks@vt.edu wrote:

> On Fri, 02 Jan 2004 22:07:48 PST, Greg KH <greg@kroah.com>  said:
> 
> > What is "efficiently"?  No one really cares about milliseconds here,
> > seconds are even tollerable at least for small seconds :)
> 
> Anybody who's had to sit and watch a Sun E10K enumerate 400+ disks
> will disagree with that, unless "small seconds" are tiny fractions thereof. :)
> 
> 
> 

Even an old E3500 with only 70 or so disks and the evil RDAC is enough.

Ian

Re: udev and devfs - The final word

[Greg KH]

On Sat, Jan 03, 2004 at 01:51:08AM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 02 Jan 2004 22:07:48 PST, Greg KH <greg@kroah.com>  said:
> 
> > What is "efficiently"?  No one really cares about milliseconds here,
> > seconds are even tollerable at least for small seconds :)
> 
> Anybody who's had to sit and watch a Sun E10K enumerate 400+ disks
> will disagree with that, unless "small seconds" are tiny fractions thereof. :)

It's "small seconds" _after_ the kernel has enumerated them.  That's the
majority of the time spent enumerating scsi disks.

Also, udev will be running while the kernel is off detecting the next
disk.

thanks,

greg k-h

Re: udev and devfs - The final word

[Olaf Hering]

 On Thu, Jan 01, Rob Landley wrote:

> Fundamental problem: "Unique" depends on the other devices in the system.  You 
> can't guarantee unique by looking at one device, more or less by definition.

This is certainly not true. (well, maybe for a few device types).

Almost everything can be reached via a well defined bus (or more than
one bus). Each of them does obviously require an identifier. Thats the
hardware part.
Software tends to put a unique identifier into the 'logical' stuff, like
filesystem UUIDs.
So you can construct a unique device node for every device in the
system. And this will work even across distributions!
Stuff like sda3, mouse1 or dsp0 will obviously break. It just happend to
work because everyone on this list knows what to do and where to look.

Sure, there are exceptions, like 2 identical mice, or 2 identical USB
audio devices. But this cant be fixed.

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Re: udev and devfs - The final word

[Rob]

On Wednesday 31 December 2003 07:31 pm, Rob Love wrote:

<snip>
> This is definitely an interesting problem space.
>
> I agree wrt just inventing consecutive numbers.  If there was a nice way
> to trivially generate a random and unique number from some
> device-inherent information, that would be nice.
>
> 	Rob Love

my first thought was hardware serial numbers, but i'm guessing they mostly 
don't exist based on the discomfort caused by the pentium 3 serial number in 
the past. my second thought was raw latency. in the real world, 2 identical 
devices of any nature are going to respond electrically at different rates. i 
kind of stole the concept from what i read about the i810 rng... quantum 
differences can distinguish between 2 of anything, and based on the response 
time, 'cookies' can be written out to keep them separately ID'd. some devices 
will get slower over time, e.g. increasing error rates and aging silicon will 
throw the 'cookie' off, so you'd re-calibrate every so often, like on a 
reboot. those are rare for some of us ;)

the big IF: can you measure that with enough precision to at least decrease 
the probablity of collision? 

-- 
Rob Couto
rpc@cafe4111.org
Rules for computing success:
1) Attitude is no substitute for competence.
2) Ease of use is no substitute for power.
3) Safety matters; use a static-free hammer.
--

Re: udev and devfs - The final word

[Tyler Hall]

Since we're moving toward treating device numbers as unique handles for 
devices in a system, why can't we just dynamically allocate them like 
process ID's? As each device driver loads and registers with the kernel, 
it can request a device number and the kernel can assign the next 
available one.

Tyler

Rob wrote:

>On Wednesday 31 December 2003 07:31 pm, Rob Love wrote:
>
><snip>
>  
>
>>This is definitely an interesting problem space.
>>
>>I agree wrt just inventing consecutive numbers.  If there was a nice way
>>to trivially generate a random and unique number from some
>>device-inherent information, that would be nice.
>>
>>	Rob Love
>>    
>>
>
>my first thought was hardware serial numbers, but i'm guessing they mostly 
>don't exist based on the discomfort caused by the pentium 3 serial number in 
>the past. my second thought was raw latency. in the real world, 2 identical 
>devices of any nature are going to respond electrically at different rates. i 
>kind of stole the concept from what i read about the i810 rng... quantum 
>differences can distinguish between 2 of anything, and based on the response 
>time, 'cookies' can be written out to keep them separately ID'd. some devices 
>will get slower over time, e.g. increasing error rates and aging silicon will 
>throw the 'cookie' off, so you'd re-calibrate every so often, like on a 
>reboot. those are rare for some of us ;)
>
>the big IF: can you measure that with enough precision to at least decrease 
>the probablity of collision? 
>
>  
>

Re: udev and devfs - The final word

[Pascal Schmidt]

On Wed, 31 Dec 2003, Greg KH wrote:

> You would not have any "extra" overhead if you don't add any new devices
> to your system.  udev only runs when /sbin/hotplug runs. As for extra
> space on your disk, this email thread is almost as big as the udev
> binary is :)

Well, but if random device numbers become a reality, udev would have
to run at boot time or I wouldn't get usable device nodes. So there
is some setup complexity (because so far I don't need a correctly setup
hotplug system at all). Not much of a problem, granted, distributions
will do this for most of us and only a few people will do it by hand.

-- 
Ciao,
Pascal

Re: udev and devfs - The final word

[Greg KH]

On Thu, Jan 01, 2004 at 05:17:50PM +0100, Pascal Schmidt wrote:
> On Wed, 31 Dec 2003, Greg KH wrote:
> 
> > You would not have any "extra" overhead if you don't add any new devices
> > to your system.  udev only runs when /sbin/hotplug runs. As for extra
> > space on your disk, this email thread is almost as big as the udev
> > binary is :)
> 
> Well, but if random device numbers become a reality, udev would have
> to run at boot time or I wouldn't get usable device nodes.

Exactly, it's on the TODO list :)

thanks,

greg k-h

Re: Wrapping jiffies [was Re: udev and devfs - The final word]

[Norman Diamond]

Pavel Machek wrote:

> BTW, as we are currently in stable series, it might be good idea to
> make jiffies start at zero...

I disagree.  The importance of fixing bugs does not decrease in stable.
Hiding bugs is still the opposite of fixing bugs.

Perhaps I misunderstand the meaning of stable, but I expected stable to mean
that efforts tend more towards fixing things so they work properly, and
unstable meant that efforts tend more towards adding features even though
they're broken at first.  Hiding a broken thing is still the opposite of
fixing a broken thing.

> Hopefully jiffie wrap had enough testing during stable...

I think you mean unstable, in which case I agree with this half of what I
think you meant.  This still doesn't give any reason to switch back to
hiding things.  In fact this doesn't give any reason to switch from a
technique that "hopefully [...] had enough testing" to a different
technique, even if logically the different technique doesn't need as much
testing.