Skip to contentSkip to conversation

devfs: remove devfs from Kconfig preventing it from being built

PATCH In review Greg KH 9 participants 12 messages Jun 21, 2005 – Jun 23, 2005 VFS

lore
Share & tools
lore

Greg KH

author
#0 lore raw

PATCH 1/1 devfs: remove devfs from Kconfig preventing it from being built

Here's a much smaller patch to simply disable devfs from the build. If this goes well, and there are no complaints for a few weeks, I'll resend my big "devfs-die-die-die" series of patches that rip the whole thing out of the kernel tree.

---
 fs/Kconfig |   50 --------------------------------------------------
 1 files changed, 50 deletions(-)
fs/Kconfig +0 -50
@@ -741,56 +741,6 @@
 
 	Designers of embedded systems may wish to say N here to conserve space.
 
-config DEVFS_FS
-	bool "/dev file system support (OBSOLETE)"
-	depends on EXPERIMENTAL
-	help
-	  This is support for devfs, a virtual file system (like /proc) which
-	  provides the file system interface to device drivers, normally found
-	  in /dev. Devfs does not depend on major and minor number
-	  allocations. Device drivers register entries in /dev which then
-	  appear automatically, which means that the system administrator does
-	  not have to create character and block special device files in the
-	  /dev directory using the mknod command (or MAKEDEV script) anymore.
-
-	  This is work in progress. If you want to use this, you *must* read
-	  the material in <file:Documentation/filesystems/devfs/>, especially
-	  the file README there.
-
-	  Note that devfs no longer manages /dev/pts!  If you are using UNIX98
-	  ptys, you will also need to mount the /dev/pts filesystem (devpts).
-
-	  Note that devfs has been obsoleted by udev,
-	  <http://www.kernel.org/pub/linux/utils/kernel/hotplug/>.
-	  It has been stripped down to a bare minimum and is only provided for
-	  legacy installations that use its naming scheme which is
-	  unfortunately different from the names normal Linux installations
-	  use.
-
-	  If unsure, say N.
-
-config DEVFS_MOUNT
-	bool "Automatically mount at boot"
-	depends on DEVFS_FS
-	help
-	  This option appears if you have CONFIG_DEVFS_FS enabled. Setting
-	  this to 'Y' will make the kernel automatically mount devfs onto /dev
-	  when the system is booted, before the init thread is started.
-	  You can override this with the "devfs=nomount" boot option.
-
-	  If unsure, say N.
-
-config DEVFS_DEBUG
-	bool "Debug devfs"
-	depends on DEVFS_FS
-	help
-	  If you say Y here, then the /dev file system code will generate
-	  debugging messages. See the file
-	  <file:Documentation/filesystems/devfs/boot-options> for more
-	  details.
-
-	  If unsure, say N.
-
 config DEVPTS_FS_XATTR
 	bool "/dev/pts Extended Attributes"
 	depends on UNIX98_PTYS
#1 lore raw

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 15:24:19 -0700

Quoted 6 lines

Here's a much smaller patch to simply disable devfs from the build. If this goes well, and there are no complaints for a few weeks, I'll resend my big "devfs-die-die-die" series of patches that rip the whole thing out of the kernel tree.

I know the rational behind this.

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

author
#2 lore raw
Quoted 8 lines · David S. Miller

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 15:24:19 -0700

Quoted 5 lines

Here's a much smaller patch to simply disable devfs from the build. If this goes well, and there are no complaints for a few weeks, I'll resend my big "devfs-die-die-die" series of patches that rip the whole thing out of the kernel tree.

Quoted 7 lines
Quoted 1 line

I know the rational behind this.

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

Those boxes rely on devfs?

Can't you just grab the "static dev" debian package and continue on? I'm sure there is one in there somewhere (don't really know for sure, not running debian anywhere here, sorry.)

Or how about a tarball of a /dev tree? Would that help you out?

thanks,

greg k-h

#3 lore raw

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 21:13:30 -0700

Quoted 9 lines · David S. Miller
Quoted 6 lines

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 15:24:19 -0700

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

Those boxes rely on devfs?

Yeah, when I forget to turn on DEVFS_FS and DEVFS_MOUNT in the kernel config the machine won't boot. :-)

Quoted 5 lines

Can't you just grab the "static dev" debian package and continue on? I'm sure there is one in there somewhere (don't really know for sure, not running debian anywhere here, sorry.)

Or how about a tarball of a /dev tree? Would that help you out?

I don't know if Debian has such a package.

Don't worry, I'll take care of this by simply reinstalling and thus moving to udev.

#4 lore raw
Quoted 13 lines
Quoted 5 lines
Quoted 3 lines

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

Those boxes rely on devfs?

Yeah, when I forget to turn on DEVFS_FS and DEVFS_MOUNT in the kernel config the machine won't boot. :-)

Quoted 4 lines

Can't you just grab the "static dev" debian package and continue on? I'm sure there is one in there somewhere (don't really know for sure, not running debian anywhere here, sorry.)

Quoted 6 lines
Quoted 1 line

Or how about a tarball of a /dev tree? Would that help you out?

I don't know if Debian has such a package.

Don't worry, I'll take care of this by simply reinstalling and thus moving to udev.

??? I use debian sarge all the time with kernel.org kernels that don't have devfs compiled in, and I don't use udev either. Works across ia32, x86_64, and PPC64 (32 bit userspace) at least, with no trouble at all, out of the box. I did the same with Woody as well before that ...

M.

#5 lore raw
Quoted 17 lines · Martin J. Bligh
Quoted 17 lines
Quoted 5 lines
Quoted 3 lines

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

Those boxes rely on devfs?

Yeah, when I forget to turn on DEVFS_FS and DEVFS_MOUNT in the kernel config the machine won't boot. :-)

Quoted 5 lines

Can't you just grab the "static dev" debian package and continue on? I'm sure there is one in there somewhere (don't really know for sure, not running debian anywhere here, sorry.)

Or how about a tarball of a /dev tree? Would that help you out?

I don't know if Debian has such a package.

Quoted 7 lines
Quoted 2 lines

Don't worry, I'll take care of this by simply reinstalling and thus moving to udev.

??? I use debian sarge all the time with kernel.org kernels that don't have devfs compiled in, and I don't use udev either. Works across ia32, x86_64, and PPC64 (32 bit userspace) at least, with no trouble at all, out of the box. I did the same with Woody as well before that ...

I think he's just saying that since he did the install with devfs enabled and has been using devfs device names, a conversion back to 'standard' names would be a major PITA. It's definately possible to convert, but if there's not much on the boxes a reinstall might be quicker.

Quoted 2 lines

M.

Jim.

Quoted 6 lines

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#6 lore raw
In reply to David S. Miller
Quoted 7 lines · David S. Miller

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 21:13:30 -0700

Quoted 4 lines · David S. Miller
Quoted 3 lines

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 15:24:19 -0700

Quoted 14 lines
Quoted 5 lines
Quoted 3 lines

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

Those boxes rely on devfs?

Yeah, when I forget to turn on DEVFS_FS and DEVFS_MOUNT in the kernel config the machine won't boot. :-)

Quoted 5 lines

Can't you just grab the "static dev" debian package and continue on? I'm sure there is one in there somewhere (don't really know for sure, not running debian anywhere here, sorry.)

Or how about a tarball of a /dev tree? Would that help you out?

There's /sbin/MAKEDEV on debian.

Quoted 5 lines

I don't know if Debian has such a package.

Don't worry, I'll take care of this by simply reinstalling and thus moving to udev.

Moving to udev is right. Still you need a "static dev" in case your udev not working.

Use /sbin/MAKEDEV from makedev package.

Signature · 2 lines
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
#7 lore raw
Quoted 28 lines · Coywolf Qi Hunt
Quoted 7 lines · David S. Miller

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 21:13:30 -0700

Quoted 4 lines · David S. Miller
Quoted 3 lines

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 15:24:19 -0700

Quoted 14 lines
Quoted 5 lines
Quoted 3 lines

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

Those boxes rely on devfs?

Yeah, when I forget to turn on DEVFS_FS and DEVFS_MOUNT in the kernel config the machine won't boot. :-)

Quoted 5 lines

Can't you just grab the "static dev" debian package and continue on? I'm sure there is one in there somewhere (don't really know for sure, not running debian anywhere here, sorry.)

Or how about a tarball of a /dev tree? Would that help you out?

There's /sbin/MAKEDEV on debian.

Quoted 3 lines

I don't know if Debian has such a package.

Quoted 8 lines
Quoted 2 lines

Don't worry, I'll take care of this by simply reinstalling and thus moving to udev.

Moving to udev is right. Still you need a "static dev" in case your udev not working.

Use /sbin/MAKEDEV from makedev package.

A nice addition to udev package would be an standard minimal /dev tree to allow booting till init and running udev as the first thing... A tar.gz you could just unpack on a new box or on an initrd.

;)

--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam1 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))

#8 lore raw
Quoted 36 lines · J.A. Magallon
Quoted 34 lines · Coywolf Qi Hunt
Quoted 7 lines · David S. Miller

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 21:13:30 -0700

Quoted 4 lines · David S. Miller
Quoted 3 lines

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 15:24:19 -0700

Quoted 14 lines
Quoted 5 lines
Quoted 3 lines

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

Those boxes rely on devfs?

Yeah, when I forget to turn on DEVFS_FS and DEVFS_MOUNT in the kernel config the machine won't boot. :-)

Quoted 5 lines

Can't you just grab the "static dev" debian package and continue on? I'm sure there is one in there somewhere (don't really know for sure, not running debian anywhere here, sorry.)

Or how about a tarball of a /dev tree? Would that help you out?

There's /sbin/MAKEDEV on debian.

Quoted 5 lines

I don't know if Debian has such a package.

Don't worry, I'll take care of this by simply reinstalling and thus moving to udev.

Moving to udev is right. Still you need a "static dev" in case your udev not working.

Quoted 8 lines
Quoted 2 lines

Use /sbin/MAKEDEV from makedev package.

A nice addition to udev package would be an standard minimal /dev tree to allow booting till init and running udev as the first thing... A tar.gz you could just unpack on a new box or on an initrd.

;)

I guess we've already got one in initramfs.
The "static" /dev is still necessary. I once killed my udevd, and the static /dev revealed.

Signature · 2 lines
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
#9 lore raw
In reply to David S. Miller
Quoted 29 lines · David S. Miller

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 21:13:30 -0700

Quoted 6 lines · David S. Miller
Quoted 5 lines

From: Greg KH <[email protected]>
Date: Tue, 21 Jun 2005 15:24:19 -0700

Quoted 8 lines
Quoted 5 lines

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

Those boxes rely on devfs?

Yeah, when I forget to turn on DEVFS_FS and DEVFS_MOUNT in the kernel config the machine won't boot. :-)

Quoted 4 lines

Can't you just grab the "static dev" debian package and continue on? I'm sure there is one in there somewhere (don't really know for sure, not running debian anywhere here, sorry.)

Quoted 9 lines
Quoted 3 lines

Or how about a tarball of a /dev tree? Would that help you out?

I don't know if Debian has such a package.

Don't worry, I'll take care of this by simply reinstalling and thus moving to udev.

That works, but seems like "the long way".
You don't need to be given a tarball of a /dev tree - make your own! tar up your existing devfs-based /dev tree (at a time when all your devices are present) then umount devfs and untar it
all. Then you have a static /dev which works with the existing setup,
and a nondevfs kernel can boot right away.

The udev way may be necessary if you actually have lots of devices that come and go, such as usb thingies. It shouldn't be necessary just to boot the machine though.

Quoted 4 lines · Jim Crilly

I think he's just saying that since he did the install with devfs enabled and has been using devfs device names, a conversion back to 'standard' names would be a major PITA. It's definately possible to convert, but if there's not much on the boxes a reinstall might be quicker.

Fortunately, one doesn't need to convert back. Just copy devfs-dev onto ext3-dev and there you have the "good old" devfs-names in a static /dev.

Helge Hafting

#10 lore raw
In reply to David S. Miller
Quoted 5 lines · David S. Miller

I know the rational behind this.

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

I have half a dozend debian sarge,etch and sid boxes on various architectures and they work just fine without devfs.

#11 lore raw
Quoted 9 lines · Christoph Hellwig
Quoted 5 lines · David S. Miller

I know the rational behind this.

However, this does mean I do need to reinstall a couple debian boxes here to something newer before I can continue doing kernel work in 2.6.x on them.

I have half a dozend debian sarge,etch and sid boxes on various architectures and they work just fine without devfs.

Everything works until you put your root filesystem on LVM (or RAID, perhaps, but I've never used that so can't be sure).

The Debian initrd-tools rely on devfs to populate block devices corresponding to physical disks. If you explictlly name your root filesystem, you're safe even without devfs, because the initrd's /sbin/init script also explicitly mknods your root device --- but if your root filesystem is on LVM, well, vgscan needs to search your physical disks, which means that they have to exist *before* vgscan runs, for which it uses devfs and only devfs.

Debian users in this situation can always build their own initrds --- I did --- but it's, er, not something I'd expect users to be able to do.

Of course, killing off devfs now might prod the Debian maintainers into populating physical devices using udev instead ;)

(There is a Debian bug for this, #312871. It's marked as wishlist, which strikes me as much too low.)

Signature · 2 lines
`It's as bizarre an intrusion as, I don't know, the hobbits coming home
 to find that the Shire has been taken over by gangsta rappers.'