Re: [2.4.0] migration to devfs
[EMAIL PROTECTED] writes: > Can you give us a rundown on how to get this to work? I followed the > instructions in the README but the permissions and owner/group bits never > stayed the way I wanted them. (eg: root.audio for all of /dev/sound, If you use devfsd from unstable then there is a file /etc/devfs/devfsd.conf. There you have to uncomment the following section (or, if you create a new devfsd.conf file, just add the following commands): - # Sample /etc/devfsd.conf configuration file. # # Uncomment this if you want permissions to be saved and restored #REGISTER .* COPY/dev-state/$devname $devpath #CHANGE .* COPY$devpath /dev-state/$devname #CREATE .* COPY$devpath /dev-state/$devname - -- Until the next mail..., Stefan.
Re: [2.4.0] migration to devfs
> That installed a script(s?) in /etc/init.d, which start devfsd at > boot-time. Of course, you have to have the kernel automatically mount > devfs in /dev, which is available as an option in the kernel > pre-compilation configuration. If you didn't select it there, add > "devfs=mount" as an argument to the kernel, either through > /etc/lilo.conf, or at the boot-time LILO prompt. > > Then, it Just Worked(tm). All ownerships and permissions are as I'd > expect, including /dev/sound and friends. I did the same thing and now it Just Worked(tm). Shrug. Don't know what I was doing wrong before. I had to add the following lines to /etc/devfsd/devices: # devices file # format: name [bc] major minor uid gid mode nvidia0 c 195 0 rootvideo 0660 nvidia1 c 195 1 rootvideo 0660 nvidia2 c 195 2 rootvideo 0660 nvidia3 c 195 3 rootvideo 0660 nvidiactl c 195 255 rootvideo 0660 It appeares that /etc/init.d/devfsd reads this at startup and creates the devices listed. I'm going through my conf files and changing them all over to the new devfs style entries and then will remove backwards compatability through the /etc/devfs/devfsd.conf. Thanks for the ideas.
Re: [2.4.0] migration to devfs
To quote [EMAIL PROTECTED], # Can you give us a rundown on how to get this to work? I followed the # instructions in the README but the permissions and owner/group bits never # stayed the way I wanted them. (eg: root.audio for all of /dev/sound, # root.video for all of /dev/v4l, etc). I'm using the devfsd from unstable # now. # # Also, I use the NVIDIA binary XFree86 4.0.1 driver. This driver needs # five entries in /dev to work. I can't get devfs to keep those entries # there across reboots. I made a script to do make those entries every time # the system is booted but I'm sure there is a prorper way of doing it. Since I don't know much about your system, all I can do is tell you how I got it to work. I'm running unstable(Sid), so I just did an 'apt-get install devfsd'. If you're not running Sid, I imagine you can pick up the source package, and build it(using dpkg-buildpackage). You could also temporarily change the 'deb-src' line in your /etc/apt/sources.list to point to "unstable", and do an 'apt-get -b source devfsd'. That installed a script(s?) in /etc/init.d, which start devfsd at boot-time. Of course, you have to have the kernel automatically mount devfs in /dev, which is available as an option in the kernel pre-compilation configuration. If you didn't select it there, add "devfs=mount" as an argument to the kernel, either through /etc/lilo.conf, or at the boot-time LILO prompt. Then, it Just Worked(tm). All ownerships and permissions are as I'd expect, including /dev/sound and friends. If this doesn't work for you, would you mind giving us a bit more information? Some things of note: What devfs-related options you configured in your kernel, how devfs is being mounted to /dev, how devfsd was installed, and anything else that is related. :) Dave
Re: [2.4.0] migration to devfs
> > chgrp wheel /dev/somedevice > > chmod 660 /dev/somedevice > > > > and have it stick. (past reboots) > > With devfsd this is also very simple possible. Can you give us a rundown on how to get this to work? I followed the instructions in the README but the permissions and owner/group bits never stayed the way I wanted them. (eg: root.audio for all of /dev/sound, root.video for all of /dev/v4l, etc). I'm using the devfsd from unstable now. Also, I use the NVIDIA binary XFree86 4.0.1 driver. This driver needs five entries in /dev to work. I can't get devfs to keep those entries there across reboots. I made a script to do make those entries every time the system is booted but I'm sure there is a prorper way of doing it. Any help? Thanks.
Re: [2.4.0] migration to devfs
To quote Stefan Nobis <[EMAIL PROTECTED]>, # No, but Andreas stated clearly that he don't want to use devfsd. And the above # are the internal names of devfs and the device drivers. The other names like # /dev/discs/disc0 and the like are the user friendly naming scheme which is # brought to you with devfsd. So if you don't use devfsd you don't get the new, # shorter names but only the very long internal names (which are deprecated to # use). Incorrect; on my system, the shortened names exist without devfsd. Observe: [EMAIL PROTECTED] /home/david]# ps aux | grep devfs | grep -v grep [EMAIL PROTECTED] /home/david]# mount -t devfs none /dev [EMAIL PROTECTED] /home/david]# ps aux | grep devfs | grep -v grep [EMAIL PROTECTED] /home/david]# ls /dev/discs/ total 0 lr-xr-xr-x1 root root 30 Dec 31 1969 disc0 -> ../ide/host0/bus0/target0/lun0 lr-xr-xr-x1 root root 30 Dec 31 1969 disc1 -> ../ide/host0/bus1/target1/lun0 [EMAIL PROTECTED] /home/david]# ps aux | grep devfs | grep -v grep [EMAIL PROTECTED] /home/david]# Tada :) They do exist. It's still longer than '/dev/hda1', but '/dev/discs/disc0/part1' isn't all that bad. Dave
Re: [2.4.0] migration to devfs
Ethan Benson <[EMAIL PROTECTED]> writes: > very funny, im sure you would like it if someone FORCED you to use > *only* KDE or *only* gnome. the Free software movement is about > freedom and choices and *options* i should have the *option* to turn > that `feature' off. > > don't force your preferences on others. you like devfs use it, don't > force me to do the same. > as soon as there is no longer any choices or options in GNU/Linux is > it no better for me then Windows. Hey, than Linux is no better then Windows. Did you know that they changed the way the caching and the VM works? And the worst: They let you no choice to use the old system! How could they do without asking you! These bad guys! -- Until the next mail..., Stefan.
Re: [2.4.0] migration to devfs
Brian May <[EMAIL PROTECTED]> writes: > > "Andreas" == Andreas Jellinghaus <[EMAIL PROTECTED]> writes: > > Andreas> 2.) boot. fsck will fail. do manual fsck, remount / rw, > Andreas> edit /etc/fstab: /dev/ide/host0/bus0/target0/lun0/part1 > Andreas> /boot ext2 defaults 0 2 > Andreas> /dev/ide/host0/bus0/target0/lun0/part2 none swap sw 0 0 > Andreas> /dev/ide/host0/bus0/target0/lun0/part5 / ext2 defaults 0 > Andreas> 1 /dev/ide/host0/bus0/target0/lun0/part6 /local ext2 > Andreas> defaults 0 2 /dev/ide/host0/bus0/tagret1/lun0/cd /cdrom > Andreas> iso9660 ro,user,noauto > > This seems to be overly complex, even for devfs. Or is the > documentation found in > linux-2.4.0-test10/Documentation/filesystems/devfs/README out-of-date > or wrong? No, but Andreas stated clearly that he don't want to use devfsd. And the above are the internal names of devfs and the device drivers. The other names like /dev/discs/disc0 and the like are the user friendly naming scheme which is brought to you with devfsd. So if you don't use devfsd you don't get the new, shorter names but only the very long internal names (which are deprecated to use). -- Until the next mail..., Stefan.
Re: [2.4.0] migration to devfs
Ethan Benson <[EMAIL PROTECTED]> writes: > instead of /dev/hda1 or /dev/wd0a whenever i need to do anything > related to raw devices is a performance improvment. nor is writing > huge kludgy initscripts or bloated daemons just so i can do: I can't see why a daemon about 30k in size is bloated. See it this way: The old way to manage devices is with major/minor node numbers. There are not much free numbers these days and if we put the system to 32 Bit numbers or the like, the kernel will be very much more bloated than that small daemon in user-mode could ever be bloated. One other IMO very good argument is, that with the old system the list of numbers is used at two different locations, one in the kernel and one in /dev or MAKEDEV scripts. With devfs there is now only one list in the kernel. (Not to mention that numbers are given in a very chaotic way to devices.) Last but not least without /dev being an ordinary directory one is much more flexible with the root-dir. It's much more simple now to make / read-only without the need vor a ramdisk and the like. And at least i'm very pleased that now i can have a look in /dev and see what's really there. By the way i love dynamically managed resources and i don't like the idea that resources are managed statically -- only think about USB. > chgrp wheel /dev/somedevice > chmod 660 /dev/somedevice > > and have it stick. (past reboots) With devfsd this is also very simple possible. -- Until the next mail..., Stefan.
Re: [2.4.0] migration to devfs
> lr-xr-xr-x1 root root 33 Jan 1 1970 /dev/cdroms/cdrom0 -> > ../ide/host0/bus1/target1/lun0/cd > lr-xr-xr-x1 root root 30 Jan 1 1970 /dev/discs/disc0 -> > ../ide/host0/bus0/target0/lun0/ > lr-xr-xr-x1 root root 30 Jan 1 1970 /dev/discs/disc1 -> > ../ide/host0/bus0/target1/lun0/ > lr-xr-xr-x1 root root 30 Jan 1 1970 /dev/discs/disc2 -> > ../ide/host0/bus1/target0/lun0/ Did those people who whine actaully read the above (and ofcourse the reasons to switch to devfs, instead of that 'hack', although this isn't perfect too, it's getting better !) ?
Re: [2.4.0] migration to devfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A long time ago, in a galaxy far, far way, someone said... > On Sat, Jan 06, 2001 at 06:09:54PM +0100, Andreas Jellinghaus wrote: > > 2.) boot. fsck will fail. do manual fsck, remount / rw, edit /etc/fstab: > > /dev/ide/host0/bus0/target0/lun0/part1 /boot ext2 defaults 0 2 > > /dev/ide/host0/bus0/target0/lun0/part2 none swap sw 0 > > 0 > > /dev/ide/host0/bus0/target0/lun0/part5 / ext2 defaults 0 > > 1 > > /dev/ide/host0/bus0/target0/lun0/part6 /local ext2 defaults 0 2 > > /dev/ide/host0/bus0/tagret1/lun0/cd /cdrom iso9660 ro,user,noauto > > all i can say is if this hideous thing is ever forced down our throats > i will switch to another OS. Note that the names under /dev/ are administrator configurable. - -- - -- Phil Brutsche [EMAIL PROTECTED] GPG fingerprint: 9BF9 D84C 37D0 4FA7 1F2D 7E5E FD94 D264 50DE 1CFC GPG key id: 50DE1CFC GPG public key: http://tux.creighton.edu/~pbrutsch/gpg-public-key.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6V9Wv/ZTSZFDeHPwRAmSUAKCOG5I8fejmMUIrWH4gKd7AxGObZQCdFe75 CW0RdOaUVVD1lyXl+zpuV9o= =IYPq -END PGP SIGNATURE-
Re: [2.4.0] migration to devfs
Ethan Benson writes: > don't force your preferences on others. you like devfs use it, don't > force me to do the same. You are free to fork your own version of Debian and/or the Linux kernel whenever you see fit. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: [2.4.0] migration to devfs
To quote Joey Hess <[EMAIL PROTECTED]>, # So if you have a problem with something, talk to the authors. Spewing # bile across the lists of an unrelated project is just going to be # conterproductive for you in the long run. I apologize for my part in this argument. It really upsets me to see this, and I should have taken it off-list. Sorry for the inconvenience(sp?), Dave
Re: [2.4.0] migration to devfs
Ethan Benson wrote: > i have heard all the arguments for devfs (long ago on linux-kernel) i > still don't want it. i just want the option to leave it off is that > so much to ask? I'm puzzled. You're saying you are a subscriber to linux-kernel. So why are you posting your drivel *here*? The users of Debian can do nothing about whether the linux kernel continues to offer the option of not using devfs. The developers of Debian will do nothing about whether the linux kernel continues to offer the option of not using devfs. All you are managing to do is piss off Debian users and developers who have better things to do than listen to you bitch and moan about a hypothetical that is outside their control anyway. If I see another message from you on this thread that is substantially the same as the 9 you just posted, then I will probably killfile you. That would be a pity, if at some time in the future you had a legitimate problem with part of Debian which I am responsible for, and were unable to communicate it to me. So if you have a problem with something, talk to the authors. Spewing bile across the lists of an unrelated project is just going to be conterproductive for you in the long run. -- see shy jo
Re: [2.4.0] migration to devfs
On Sun, Jan 07, 2001 at 12:03:54PM +1100, Brian May wrote: > > My understanding is that chown/chgrp/chmod will work fine without > devfsd. as long as you never reboot. i don't reboot often, but i have to do it from time to time. i have heard all the arguments for devfs (long ago on linux-kernel) i still don't want it. i just want the option to leave it off is that so much to ask? -- Ethan Benson http://www.alaska.net/~erbenson/ pgp1IZrJSuEn1.pgp Description: PGP signature
Re: [2.4.0] migration to devfs
To quote Ethan Benson <[EMAIL PROTECTED]>, # On Sat, Jan 06, 2001 at 07:46:53PM -0500, David B. Harris wrote: # > You might want to consider changing your attitude a bit. These people # # oh i want choice, my attitude is clearly flawed afterall if i did not # want choice i would still be letting MS or Apple tell me what to do. Yes, your attitude *is* clearly flawed. Whether or not you get a choice is irrelevant. These people put their blood and sweat into something which you directly benefit from(which no recompensation for you, either, I bet). And you have the *gall* to demand ANYTHING? That's the flaw. Not that you want choice - but that you demand it from people who have done nothing but work for you, for free. Dave
Re: [2.4.0] migration to devfs
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: Ethan> On Sat, Jan 06, 2001 at 06:38:16PM -0600, Jason Holland Ethan> wrote: >> Devfs has a compatibility mode which can be turned on. it >> enables the old device paths, like /dev/hda4, to coexist with >> the new paths, though mount will report the new path. Ethan> it does that though a kludge daemon. the same kludge Ethan> required to allow chown/chgrp/chmod to work. My understanding is that chown/chgrp/chmod will work fine without devfsd. My understanding is devfs can do these tasks: 1. register compatibility links. 2. Setup default permissions of devices as they are created. 3. Automatically load kernel modules as required if required device does not exist. It is not required for devfs support, as other methods could be used instead. It is the method recommended by the author though. -- Brian May <[EMAIL PROTECTED]>
Re: [2.4.0] migration to devfs
On Sun, Jan 07, 2001 at 11:52:17AM +1100, Brian May wrote: > > Have a look at Documentation/filesystems/devfs/README, with the Linux > kernel (at least 2.4.0test10) - there are a number of good reasons for > why devfs is required, mentioned there. I recommend anyone interested > in devfs should read this first before posting to this thread. i have read that and other documents on devfs, i still don't buy it and i still don't want it. and devfs is certainly *NOT* required. i just hope it stays that way. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpOePFNPhMX8.pgp Description: PGP signature
Re: [2.4.0] migration to devfs
On Sun, Jan 07, 2001 at 12:51:58AM +, Pollywog wrote: > I am confused.Is there some stuff I need to read in order to > prepare for this change in my favorite OS? > Just tell me what I need to read and I will get right on it. If I > have to migrate, I need a map :) you don't need to migrate to this atrocity, i have been running a 2.4.0 kernel on one of my machines for a bit now with*out* devfs and it works quite fine. i just want to to *stay that way* -- Ethan Benson http://www.alaska.net/~erbenson/ pgpoG8qHDo4hr.pgp Description: PGP signature
Re: [2.4.0] migration to devfs
On Sat, Jan 06, 2001 at 07:46:53PM -0500, David B. Harris wrote: > You might want to consider changing your attitude a bit. These people oh i want choice, my attitude is clearly flawed afterall if i did not want choice i would still be letting MS or Apple tell me what to do. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp8iYjeivQJp.pgp Description: PGP signature
Re: [2.4.0] migration to devfs
On Sat, Jan 06, 2001 at 06:50:52PM -0600, Jason Holland wrote: > > haha! i happen to agree that the path names are ridiculous. however, i'd they certainly are rediculous. > rather have a 100 devices to look through, than 5000 without devfs turned > on. isn't it nice to have a choice? yes its great to have a *choice* and i *LIKE* having 1200 devices in /dev (5000 is simply not true, i counted 4 systems here and none exceed 1200 which is just fine, 5000 would not bother me a bit either) choice is a good thing, if i did not want choice i would be using Windows or MacOS. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpsnHPtrS8zB.pgp Description: PGP signature
Re: [2.4.0] migration to devfs
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: Ethan> On Sat, Jan 06, 2001 at 01:34:07PM -0500, S.Salman Ahmed Ethan> wrote: >> I have one question regarding devfs: does it offer any >> performance improvements over the traditional non-devfs setup, >> or is devfs simply a 'structural' change ? Ethan> i fail to see how typing: Ethan> /dev/ide/host0/bus0/target0/lun0/part1 Ethan> instead of /dev/hda1 or /dev/wd0a whenever i need to do Ethan> anything related to raw devices is a performance Have a look at Documentation/filesystems/devfs/README, with the Linux kernel (at least 2.4.0test10) - there are a number of good reasons for why devfs is required, mentioned there. I recommend anyone interested in devfs should read this first before posting to this thread. Also, yes, the first one *could* be a performance gain, because: "There is an important difference between the way disc-based character and block nodes and devfs entries make the connection between an entry in /dev and the actual device driver. With the current 8 bit major and minor numbers the connection between disc-based c&b nodes and per-major drivers is done through a fixed-length table of 128 entries. The various filesystem types set the inode operations for c&b nodes to {chr,blk}dev_inode_operations, so when a device is opened a few quick levels of indirection bring us to the driver file_operations. For miscellaneous character devices a second step is required: there is a scan for the driver entry with the same minor number as the file that was opened, and the appropriate minor open method is called. This scanning is done *every time* you open a device node. Potentially, you may be searching through dozens of misc. entries before you find your open method. While not an enormous performance overhead, this does seem pointless. [...] Note thate devfs doesn't use the major&minor system. For devfs entries, the connection is done when you lookup the /dev entry. When devfs_register() is called, an internal table is appended which has the entry name and the file_operations. If the dentry cache doesn't have the /dev entry already, this internal table is scanned to get the file_operations, and an inode is created. If the dentry cache already has the entry, there is *no lookup time* (other than the dentry scan itself, but we can't avoid that anyway, and besides Linux dentries cream other OS's which don't have them:-). Furthermore, the number of node entries in a devfs is only the number of available device entries, not the number of *conceivable* entries. Even if you remove unnecessary entries in a disc-based /dev, the number of conceivable entries remains the same: you just limit yourself in order to save space." Ethan> improvment. nor is writing huge kludgy initscripts or Ethan> bloated daemons just so i can do: I also disagree with this statement, too. -- Brian May <[EMAIL PROTECTED]>
Re: [2.4.0] migration to devfs
I am confused. Is there some stuff I need to read in order to prepare for this change in my favorite OS? Just tell me what I need to read and I will get right on it. If I have to migrate, I need a map :) -- Andrew On Sat, 6 Jan 2001 15:46:13 -0900, Ethan Benson said: > On Sat, Jan 06, 2001 at 06:38:16PM -0600, Jason Holland wrote: > > Devfs has a compatibility mode which can be turned on. it enables the old > > device paths, like /dev/hda4, to coexist with the new paths, though mount > > will report the new path. > > it does that though a kludge daemon. the same kludge required to > allow chown/chgrp/chmod to work. > > that is unacceptable, the only acceptable option is to allow: > > CONFIG_DEVFS_FS=n
RE: [2.4.0] migration to devfs
> > > On Sat, Jan 06, 2001 at 06:38:16PM -0600, Jason Holland wrote: > > Devfs has a compatibility mode which can be turned on. it > enables the old > > device paths, like /dev/hda4, to coexist with the new > paths, though mount > > will report the new path. > > it does that though a kludge daemon. the same kludge required to > allow chown/chgrp/chmod to work. > > that is unacceptable, the only acceptable option is to allow: > > CONFIG_DEVFS_FS=n > haha! i happen to agree that the path names are ridiculous. however, i'd rather have a 100 devices to look through, than 5000 without devfs turned on. isn't it nice to have a choice? Jason
Re: [2.4.0] migration to devfs
On Sat, Jan 06, 2001 at 06:38:16PM -0600, Jason Holland wrote: > Devfs has a compatibility mode which can be turned on. it enables the old > device paths, like /dev/hda4, to coexist with the new paths, though mount > will report the new path. it does that though a kludge daemon. the same kludge required to allow chown/chgrp/chmod to work. that is unacceptable, the only acceptable option is to allow: CONFIG_DEVFS_FS=n -- Ethan Benson http://www.alaska.net/~erbenson/ pgpHEgMhg8k4x.pgp Description: PGP signature
Re: [2.4.0] migration to devfs
To quote Ethan Benson <[EMAIL PROTECTED]>, # i fail to see how typing: # # /dev/ide/host0/bus0/target0/lun0/part1 # # instead of /dev/hda1 or /dev/wd0a whenever i need to do anything # related to raw devices is a performance improvment. nor is writing # huge kludgy initscripts or bloated daemons just so i can do: He didn't say that it was a performance improvement. He was asking. No need act like it was a personal attack. # anyway thats just my rant on the subject, if you like devfs use it, # but leave it an OPTION so i can leave it off. (and not an `option' # like proc has become where you have the option to turn off and have a # useless broken system) You might want to consider changing your attitude a bit. These people are putting in how much time for free? If devfs becomes one of those "must-have for a useable system" options, then put your effort where your mouth is and work on the code. Show some gratitude. Say, every now and then, "Thank you Linus, you've given me a Free Unix-close which I use." That's not so hard, is it? Dave
Re: [2.4.0] migration to devfs
On Sat, Jan 06, 2001 at 07:21:11PM -0500, David B. Harris wrote: > To quote Ethan Benson <[EMAIL PROTECTED]>, > # > 2.) boot. fsck will fail. do manual fsck, remount / rw, edit > /etc/fstab: > # > /dev/ide/host0/bus0/target0/lun0/part1 /boot ext2 defaults0 > 2 > # > /dev/ide/host0/bus0/target0/lun0/part2 none swap sw 0 > 0 > # > /dev/ide/host0/bus0/target0/lun0/part5 / ext2 defaults0 > 1 > # > /dev/ide/host0/bus0/target0/lun0/part6 /local ext2 defaults 0 > 2 > # > /dev/ide/host0/bus0/tagret1/lun0/cd /cdrom iso9660 ro,user,noauto > # > # all i can say is if this hideous thing is ever forced down our throats > # i will switch to another OS. > > Don't let the door hit you on the way out :) very funny, im sure you would like it if someone FORCED you to use *only* KDE or *only* gnome. the Free software movement is about freedom and choices and *options* i should have the *option* to turn that `feature' off. don't force your preferences on others. you like devfs use it, don't force me to do the same. as soon as there is no longer any choices or options in GNU/Linux is it no better for me then Windows. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpovgJkHqLxt.pgp Description: PGP signature
RE: [2.4.0] migration to devfs
Devfs has a compatibility mode which can be turned on. it enables the old device paths, like /dev/hda4, to coexist with the new paths, though mount will report the new path. Jason > > > On Sat, Jan 06, 2001 at 01:34:07PM -0500, S.Salman Ahmed wrote: > > > > I have one question regarding devfs: does it offer any performance > > improvements over the traditional non-devfs setup, or is > devfs simply a > > 'structural' change ? > > i fail to see how typing: > > /dev/ide/host0/bus0/target0/lun0/part1 > > instead of /dev/hda1 or /dev/wd0a whenever i need to do anything > related to raw devices is a performance improvment. nor is writing > huge kludgy initscripts or bloated daemons just so i can do: > > chgrp wheel /dev/somedevice > chmod 660 /dev/somedevice > > and have it stick. (past reboots) > > as for anyone attempting to make the silly claim that /dev has > thousands of devices and thus incurs the evil ext2fs directory > slowness ask them why they are not turning /usr/bin into a fake > filesystem. > > [EMAIL PROTECTED] eb]$ ls -1 /dev | wc -l >1222 > [EMAIL PROTECTED] eb]$ ls -1 /usr/bin | wc -l >2109 > [EMAIL PROTECTED] eb]$ > > the only directory on my system which i can even percieve the > slightest slowdown is /var/lib/dpkg/info, and even then its hardly > noticable nor anything to cry about: > > [EMAIL PROTECTED] eb]$ ls -1 /var/lib/dpkg/info | wc -l >5289 > [EMAIL PROTECTED] eb]$ > > better solutions to ext2 directory performance is fix the filesystem, > reiserfs does not have this problem and i think ext3 does not either. > > the only other argument i ever hear is whining about device files with > no corrosponding device, well i could care less. if i will never will > have the device and it bothers me THAT much rm -f /dev/somedevice*. > otherwise its nice to know exactly what permissions some hardware will > have before installing it. /dev is not a database of what hardware is > installed, that belongs to /sbin/lspci and /proc (though proc is a > hideous mess, everything except processes should have been moved to > /kern long ago) > > anyway thats just my rant on the subject, if you like devfs use it, > but leave it an OPTION so i can leave it off. (and not an `option' > like proc has become where you have the option to turn off and have a > useless broken system) > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ >
Re: [2.4.0] migration to devfs
On Sat, Jan 06, 2001 at 01:34:07PM -0500, S.Salman Ahmed wrote: > > I have one question regarding devfs: does it offer any performance > improvements over the traditional non-devfs setup, or is devfs simply a > 'structural' change ? i fail to see how typing: /dev/ide/host0/bus0/target0/lun0/part1 instead of /dev/hda1 or /dev/wd0a whenever i need to do anything related to raw devices is a performance improvment. nor is writing huge kludgy initscripts or bloated daemons just so i can do: chgrp wheel /dev/somedevice chmod 660 /dev/somedevice and have it stick. (past reboots) as for anyone attempting to make the silly claim that /dev has thousands of devices and thus incurs the evil ext2fs directory slowness ask them why they are not turning /usr/bin into a fake filesystem. [EMAIL PROTECTED] eb]$ ls -1 /dev | wc -l 1222 [EMAIL PROTECTED] eb]$ ls -1 /usr/bin | wc -l 2109 [EMAIL PROTECTED] eb]$ the only directory on my system which i can even percieve the slightest slowdown is /var/lib/dpkg/info, and even then its hardly noticable nor anything to cry about: [EMAIL PROTECTED] eb]$ ls -1 /var/lib/dpkg/info | wc -l 5289 [EMAIL PROTECTED] eb]$ better solutions to ext2 directory performance is fix the filesystem, reiserfs does not have this problem and i think ext3 does not either. the only other argument i ever hear is whining about device files with no corrosponding device, well i could care less. if i will never will have the device and it bothers me THAT much rm -f /dev/somedevice*. otherwise its nice to know exactly what permissions some hardware will have before installing it. /dev is not a database of what hardware is installed, that belongs to /sbin/lspci and /proc (though proc is a hideous mess, everything except processes should have been moved to /kern long ago) anyway thats just my rant on the subject, if you like devfs use it, but leave it an OPTION so i can leave it off. (and not an `option' like proc has become where you have the option to turn off and have a useless broken system) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpw2JfCmIEhZ.pgp Description: PGP signature
Re: [2.4.0] migration to devfs
> "Andreas" == Andreas Jellinghaus <[EMAIL PROTECTED]> writes: Andreas> 2.) boot. fsck will fail. do manual fsck, remount / rw, Andreas> edit /etc/fstab: /dev/ide/host0/bus0/target0/lun0/part1 Andreas> /boot ext2 defaults 0 2 Andreas> /dev/ide/host0/bus0/target0/lun0/part2 none swap sw 0 0 Andreas> /dev/ide/host0/bus0/target0/lun0/part5 / ext2 defaults 0 Andreas> 1 /dev/ide/host0/bus0/target0/lun0/part6 /local ext2 Andreas> defaults 0 2 /dev/ide/host0/bus0/tagret1/lun0/cd /cdrom Andreas> iso9660 ro,user,noauto This seems to be overly complex, even for devfs. Or is the documentation found in linux-2.4.0-test10/Documentation/filesystems/devfs/README out-of-date or wrong? Disc Devices All discs, whether SCSI, IDE or whatever, are placed under the /dev/discs hierarchy: /dev/discs/disc0first disc /dev/discs/disc1second disc Each of these entries is a symbolic link to the directory for that device. The device directory contains: discfor the whole disc part* for individual partitions CD-ROM Devices All CD-ROMs, whether SCSI, IDE or whatever, are placed under the /dev/cdroms hierarchy: /dev/cdroms/cdrom0 first CD-ROM /dev/cdroms/cdrom1 second CD-ROM Each of these entries is a symbolic link to the real device entry for that device. So, on my system, I have: lr-xr-xr-x1 root root 33 Jan 1 1970 /dev/cdroms/cdrom0 -> ../ide/host0/bus1/target1/lun0/cd lr-xr-xr-x1 root root 30 Jan 1 1970 /dev/discs/disc0 -> ../ide/host0/bus0/target0/lun0/ lr-xr-xr-x1 root root 30 Jan 1 1970 /dev/discs/disc1 -> ../ide/host0/bus0/target1/lun0/ lr-xr-xr-x1 root root 30 Jan 1 1970 /dev/discs/disc2 -> ../ide/host0/bus1/target0/lun0/ IMHO using the value on the left is much more straight forward then using the value on the right. -- Brian May <[EMAIL PROTECTED]>
Re: [2.4.0] migration to devfs
To quote Ethan Benson <[EMAIL PROTECTED]>, # > 2.) boot. fsck will fail. do manual fsck, remount / rw, edit /etc/fstab: # > /dev/ide/host0/bus0/target0/lun0/part1 /boot ext2 defaults 0 2 # > /dev/ide/host0/bus0/target0/lun0/part2 none swap sw 0 0 # > /dev/ide/host0/bus0/target0/lun0/part5 / ext2 defaults 0 1 # > /dev/ide/host0/bus0/target0/lun0/part6 /local ext2 defaults 0 2 # > /dev/ide/host0/bus0/tagret1/lun0/cd /cdrom iso9660 ro,user,noauto # # all i can say is if this hideous thing is ever forced down our throats # i will switch to another OS. Don't let the door hit you on the way out :) Dave
Re: [2.4.0] migration to devfs
On Sat, Jan 06, 2001 at 06:09:54PM +0100, Andreas Jellinghaus wrote: > 2.) boot. fsck will fail. do manual fsck, remount / rw, edit /etc/fstab: > /dev/ide/host0/bus0/target0/lun0/part1 /boot ext2 defaults0 2 > /dev/ide/host0/bus0/target0/lun0/part2 none swap sw 0 > 0 > /dev/ide/host0/bus0/target0/lun0/part5 / ext2 defaults0 > 1 > /dev/ide/host0/bus0/target0/lun0/part6 /local ext2 defaults 0 2 > /dev/ide/host0/bus0/tagret1/lun0/cd /cdrom iso9660 ro,user,noauto all i can say is if this hideous thing is ever forced down our throats i will switch to another OS. > 1.) compile a 2.4.* kernel with > CONFIG_DEVFS_FS=y i'll take CONFIG_DEVFS_FS=n thank you. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpZN2ARcr4dJ.pgp Description: PGP signature
[2.4.0] migration to devfs
these are my notes when migrating to devfs. this is meant as a true migration: i don't use that silly daemon for compatibility with older software. don't do this, unless you know what you do. regards, andreas p.s. please CC: all comments to me, i don't read much of debian-user... 1.) compile a 2.4.* kernel with CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y 2.) boot. fsck will fail. do manual fsck, remount / rw, edit /etc/fstab: /dev/ide/host0/bus0/target0/lun0/part1 /boot ext2 defaults 0 2 /dev/ide/host0/bus0/target0/lun0/part2 none swap sw 0 0 /dev/ide/host0/bus0/target0/lun0/part5 / ext2 defaults 0 1 /dev/ide/host0/bus0/target0/lun0/part6 /local ext2 defaults 0 2 /dev/ide/host0/bus0/tagret1/lun0/cd /cdrom iso9660 ro,user,noauto 3.) edit syslogd: kill lines with devices like /dev/tty12 or /dev/xconsole (an xterm with "tail -f /var/log/messages" can replace xconsole). 4.) edit /etc/securetty like this: vc/1 vc/2 vc/3 vc/4 vc/5 vc/6 5.) edit /etc/inittab like this: 1:2345:respawn:/sbin/getty 38400 /dev/vc/1 2:2345:respawn:/sbin/getty 38400 /dev/vc/2 3:2345:respawn:/sbin/getty 38400 /dev/vc/3 4:2345:respawn:/sbin/getty 38400 /dev/vc/4 5:2345:respawn:/sbin/getty 38400 /dev/vc/5 6:2345:respawn:/sbin/getty 38400 /dev/vc/6 6.) edit /etc/X11/XF86Config-4 like this: Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "PS/2" Option "Device" "/dev/misc/psaux" EndSection 7.) edit /etc/isdn/init.d.functions, change all references to "/dev/" to "/dev/isdn" (except those for /dev/null !). add a "ln -sf /dev/isdn/isdnctrl /dev" and "ln -sf /dev/isdn/isdninfo /dev" to some early boot script (or create one). 8.) edit /etc/init.d/hwclock (on potato debian systems): add a "ln -sf /dev/vc/1 /dev/tty1" at the beginning and a "rm /dev/tty1" at the end. 9.) in /etc/gdm/PreSession/Default: add "chown $USER /dev/sound/*" and in /etc/gdm/PostSession/Default: add "chown root /dev/sound/*" 10.) edit /etc/printcap, replace /dev/lp1 (or lp0) with /dev/printers/0 11.) serial: "/etc/init.d/serial stop" should write a new /etc/serial.conf, and everything is fine. 12.) edit /etc/init.d/makedev: comment the onyl line in start. (makedev is in /sbin for years, no nead for supporting old cruft. hey, you don´t need to create any devices anyway.) 13.) set an environment (for example in .bashrc): export CDTOOLDEV=/dev/ide/host0/bus1/target0/lun0/cd this way cdplay/cdstop/cdtools/... will work again. 14.) esd doesn´t find it´s device. use the gnome configuration stuff to add a startup programm: "esd -d /dev/sound/dsp1" done.