Re: [2.4.0] migration to devfs

2001-01-09 Thread Stefan Nobis
[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

2001-01-07 Thread iehrenwald
> 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

2001-01-07 Thread David B . Harris
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

2001-01-07 Thread iehrenwald
> > 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

2001-01-07 Thread David B . Harris
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

2001-01-07 Thread Stefan Nobis
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

2001-01-07 Thread Stefan Nobis
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

2001-01-07 Thread Stefan Nobis
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

2001-01-06 Thread Leen Besselink
> 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

2001-01-06 Thread Phil Brutsche
-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

2001-01-06 Thread John Hasler
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

2001-01-06 Thread David B . Harris
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

2001-01-06 Thread Joey Hess
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

2001-01-06 Thread Ethan Benson
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

2001-01-06 Thread David B . Harris
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

2001-01-06 Thread Brian May
> "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

2001-01-06 Thread Ethan Benson
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

2001-01-06 Thread Ethan Benson
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

2001-01-06 Thread Ethan Benson
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

2001-01-06 Thread Ethan Benson
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

2001-01-06 Thread Brian May
> "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

2001-01-06 Thread Pollywog
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

2001-01-06 Thread Jason Holland
>
>
> 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

2001-01-06 Thread Ethan Benson
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

2001-01-06 Thread David B . Harris
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

2001-01-06 Thread Ethan Benson
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

2001-01-06 Thread Jason Holland
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

2001-01-06 Thread Ethan Benson
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

2001-01-06 Thread Brian May
> "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

2001-01-06 Thread David B . Harris
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

2001-01-06 Thread Ethan Benson
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

2001-01-06 Thread Andreas Jellinghaus
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.