devfs and /proc/ide/hda
Im running kernel 2.4.1, I have entries like /proc/ide/hda, /proc/ide/ide0/hda etc irrespective of wether im using devfs or traditional device names.
Is always using traditional device names for /proc/ide intentional, or is it something nobody has gotten around to fixing yet?
Glenn
Quoted 7 lines · Glenn McGrath
Im running kernel 2.4.1, I have entries like
/proc/ide/hda,/proc/ide/ide0/hdaetc irrespective of wether im using devfs or traditional device names.Is always using traditional device names for
/proc/ideintentional, or is it something nobody has gotten around to fixing yet?
Using devfs changes the names in /dev. I don't think it is supposed to affect /proc in any way. And there are programs out that use the existing /proc - changing it won't be popular.
Helge Hafting
Quoted 7 lines · Helge Hafting
Quoted 5 lines · Glenn McGrath
Im running kernel 2.4.1, I have entries like
/proc/ide/hda,/proc/ide/ide0/hdaetc irrespective of wether im using devfs or traditional device names.
Quoted 7 lines
Quoted 2 lines
Is always using traditional device names for
/proc/ideintentional, or is it something nobody has gotten around to fixing yet?Using devfs changes the names in /dev. I don't think it is supposed to affect /proc in any way. And there are programs out that use the existing /proc - changing it won't be popular.
Well leaving it the way it is doesnt make much sense either really, it refers to devices that dont exist.
Glenn
Quoted 11 lines · Glenn McGrath
Quoted 9 lines · Helge Hafting
Quoted 6 lines · Glenn McGrath
Im running kernel 2.4.1, I have entries like
/proc/ide/hda,/proc/ide/ide0/hdaetc irrespective of wether im using devfs or traditional device names.Is always using traditional device names for
/proc/ideintentional, or is it something nobody has gotten around to fixing yet?
Quoted 8 lines
Quoted 4 lines
Using devfs changes the names in /dev. I don't think it is supposed to affect /proc in any way. And there are programs out that use the existing /proc - changing it won't be popular.
Well leaving it the way it is doesnt make much sense either really, it refers to devices that dont exist.
IMHO ide0 ide1... are naming plugs on the motherboard. They are not competing with special file names. It is a drawback of devfs to change the device name when you happen to use a hd as a removable media. hdd was disc0 and becomes disc1 when you plug in an hda...
Pierre
Signature · 3 lines
------------------------------------------------ Pierre Rousselet <[email protected]> ------------------------------------------------
Quoted 6 lines · Glenn McGrath
Im running kernel 2.4.1, I have entries like
/proc/ide/hda,/proc/ide/ide0/hdaetc irrespective of wether im using devfs or traditional device names.Is always using traditional device names for
/proc/ideintentional, or is it something nobody has gotten around to fixing yet?
If only humans look at /proc, and they like typing long names, then there is no objection against changing /proc.
As it is, however, quite a few programs look at /proc for information about devices. I don't think it would be a good idea to "fix" /proc and simultaneously break all these programs.
Quoted 2 lines · Glenn McGrath
Well leaving it the way it is doesnt make much sense either really, it refers to devices that dont exist.
You are mistaken. The existence of a device is unrekated to the name someone uses to access it. You may well use /tmp/myowndisk instead of /dev/hda. In fact some programs do precisely that and use mknod() to temporarily create a device node with known name, since they cannot guess what name you may be using for the device.
The kernel also uses names, for example in its boot messages, and it will call the device hda even when you use /tmp/myowndisk.
There is no intrinsic name for a device - at most a conventional name.
Quoted 6 lines · Guest section DW
Quoted 4 lines · Glenn McGrath
Im running kernel 2.4.1, I have entries like
/proc/ide/hda,/proc/ide/ide0/hdaetc irrespective of wether im using devfs or traditional device names.
Quoted 8 lines
Quoted 2 lines
Is always using traditional device names for
/proc/ideintentional, or is it something nobody has gotten around to fixing yet?If only humans look at /proc, and they like typing long names, then there is no objection against changing /proc.
As it is, however, quite a few programs look at /proc for information about devices. I don't think it would be a good idea to "fix" /proc and simultaneously break all these programs.
What it should do is change based on whether devfs is mounted or not. It doesn't make *any* sense to have /dev/ide/host0/foo/bar in your /proc/partitions entries if you aren't mounting devfs. The /proc/partitions entry is the only way I know of for something like LVM to determine which devices to scan for Volume Groups. If you can't read /proc/partitions, it has to attempt to scan all block devices it recognizes, regardless of whether they are actually on the system or not. This can take several minutes.
Signature · 13 lines
AJ Lewis Sistina Software Inc. Voice: 612-379-3951 1313 5th St SE, Suite 111 Fax: 612-379-3952 Minneapolis, MN 55414 E-Mail: [email protected] http://www.sistina.com Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B 52A0 941E 1261 0029 2648 Get my key at: http://www.sistina.com/~lewis/gpgkey (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys) -----Begin Obligatory Humorous Quote---------------------------------------- Choose a job you love, and you will never have to work a day in your life. -----End Obligatory Humorous Quote------------------------------------------
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == AJ Lewis <[email protected]> writes:
> On Wed, Feb 28, 2001 at 04:10:23PM +0100, Guest section DW > wrote:
>> On Wed, Feb 28, 2001 at 08:52:54PM +1100, Glenn McGrath wrote:
>>
>> > Im running kernel 2.4.1, I have entries like /proc/ide/hda, > >> /proc/ide/ide0/hda etc irrespective of wether im using devfs or >> > traditional device names. > > Is always using traditional >> device names for /proc/ide intentional, or > is it something >> nobody has gotten around to fixing yet?
>>
>> If only humans look at /proc, and they like typing long names, >> then there is no objection against changing /proc. As it is, >> however, quite a few programs look at /proc for information >> about devices. I don't think it would be a good idea to "fix" >> /proc and simultaneously break all these programs.
> What it should do is change based on whether devfs is mounted > or not. It doesn't make *any* sense to have
> /dev/ide/host0/foo/bar in your /proc/partitions entries if you > aren't mounting devfs. The /proc/partitions entry is the only > way I know of for something like LVM to determine which devices > to scan for Volume Groups. If you can't read /proc/partitions, > it has to attempt to scan all block devices it recognizes, > regardless of whether they are actually on the system or not. > This can take several minutes.
First:
% cat /proc/partitions
major minor #blocks name
3 0 20010816 ide/host0/bus0/target0/lun0/disc 3 1 192748 ide/host0/bus0/target0/lun0/part1 3 2 249007 ide/host0/bus0/target0/lun0/part2 3 3 1 ide/host0/bus0/target0/lun0/part3 3 5 289138 ide/host0/bus0/target0/lun0/part5 3 6 1951866 ide/host0/bus0/target0/lun0/part6 3 7 979933 ide/host0/bus0/target0/lun0/part7 3 8 16346106 ide/host0/bus0/target0/lun0/part8 33 0 80043264 ide/host2/bus0/target0/lun0/disc 33 1 80035798 ide/host2/bus0/target0/lun0/part1
So its already right.
Secondly with devfs, why not just scan all /dev/discs/?
% ls -l /dev/discs
total 0
lr-xr-xr-x 1 root root 30 Jan 1 1970 disc0 -> ../ide/host0/bus0/target0/lun0/ lr-xr-xr-x 1 root root 30 Jan 1 1970 disc1 -> ../ide/host2/bus0/target0/lun0/
Also if lvm opens all known devices by way of /dev/whatever while scanning, it will only find existing devices there with devfs.
MfG
Goswin
Quoted 26 lines · Goswin Brederlow
> What it should do is change based on whether devfs is mounted > or not. It doesn't make *any* sense to have
>/dev/ide/host0/foo/barin your/proc/partitionsentries if you > aren't mounting devfs. The/proc/partitionsentry is the only > way I know of for something like LVM to determine which devices > to scan for Volume Groups. If you can't read/proc/partitions, > it has to attempt to scan all block devices it recognizes, > regardless of whether they are actually on the system or not. > This can take several minutes.First:
% cat
/proc/partitions
major minor #blocks name3 0 20010816 ide/host0/bus0/target0/lun0/disc 3 1 192748 ide/host0/bus0/target0/lun0/part1 3 2 249007 ide/host0/bus0/target0/lun0/part2 3 3 1 ide/host0/bus0/target0/lun0/part3 3 5 289138 ide/host0/bus0/target0/lun0/part5 3 6 1951866 ide/host0/bus0/target0/lun0/part6 3 7 979933 ide/host0/bus0/target0/lun0/part7 3 8 16346106 ide/host0/bus0/target0/lun0/part8 33 0 80043264 ide/host2/bus0/target0/lun0/disc 33 1 80035798 ide/host2/bus0/target0/lun0/part1
Quoted 1 line
So its already right.
Only if devfs is mounted. That's my point. Maybe it's an corner case to have devfs compiled into the kernel, but not mounted, and so we can just ignore this, but it seems to me that /proc/partitions should reflect which /dev system is currently running.
Quoted 9 lines
Secondly with devfs, why not just scan all
/dev/discs/?% ls -l
/dev/discs
total 0lr-xr-xr-x 1 root root 30 Jan 1 1970 disc0 -> ../ide/host0/bus0/target0/lun0/ lr-xr-xr-x 1 root root 30 Jan 1 1970 disc1 -> ../ide/host2/bus0/target0/lun0/Also if lvm opens all known devices by way of
/dev/whateverwhile scanning, it will only find existing devices there with devfs.
Yeah, as long as devfs is running, that makes sense.
Signature · 14 lines
AJ Lewis Sistina Software Inc. Voice: 612-379-3951 1313 5th St SE, Suite 111 Fax: 612-379-3952 Minneapolis, MN 55414 E-Mail: [email protected] http://www.sistina.com Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B 52A0 941E 1261 0029 2648 Get my key at: http://www.sistina.com/~lewis/gpgkey (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys) -----Begin Obligatory Humorous Quote---------------------------------------- A computer without a Microsoft operating system is like a dog without bricks tied to its head. -----End Obligatory Humorous Quote------------------------------------------
Quoted 35 lines · AJ Lewis
--CblX+4bnyfN0pR09
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printableQuoted 25 lines · Goswin Brederlow
> What it should do is change based on whether devfs is mounted > or not. It doesn't make *any* sense to have
>/dev/ide/host0/foo/barin your/proc/partitionsentries if you > aren't mounting devfs. The/proc/partitionsentry is the only > way I know of for something like LVM to determine which devices > to scan for Volume Groups. If you can't read/proc/partitions, > it has to attempt to scan all block devices it recognizes, > regardless of whether they are actually on the system or not. > This can take several minutes.
=20
First:
=20
% cat /proc/partitions=20
major minor #blocks name
=203 0 20010816 ide/host0/bus0/target0/lun0/disc 3 1 192748 ide/host0/bus0/target0/lun0/part1 3 2 249007 ide/host0/bus0/target0/lun0/part2 3 3 1 ide/host0/bus0/target0/lun0/part3 3 5 289138 ide/host0/bus0/target0/lun0/part5 3 6 1951866 ide/host0/bus0/target0/lun0/part6 3 7 979933 ide/host0/bus0/target0/lun0/part7 3 8 16346106 ide/host0/bus0/target0/lun0/part8 33 0 80043264 ide/host2/bus0/target0/lun0/disc 33 1 80035798 ide/host2/bus0/target0/lun0/part1Quoted 2 lines
=20
So its already right.
Quoted 4 lines
Only if devfs is mounted. That's my point. Maybe it's an corner case to have devfs compiled into the kernel, but not mounted, and so we can just ignore this, but it seems to me that
/proc/partitionsshould reflect which /dev system is currently running.
I consider it a corner case. There isn't really an alternative. Firstly, it would be really messy to magically change the output of /proc/partitions depending on whether devfs was mounted. Secondly, just because it's mounted doesn't mean it's mounted on /dev, so it's still easy to get wrong.
Quoted 5 lines
Quoted 5 lines
Secondly with devfs, why not just scan all
/dev/discs/? =20
% ls -l /dev/discs=20
total 0
lr-xr-xr-x 1 root root 30 Jan 1 1970 disc0 -> ../ide/h=
Quoted 8 lines
ost0/bus0/target0/lun0/
Quoted 1 line
lr-xr-xr-x 1 root root 30 Jan 1 1970 disc1 -> ../ide/h=
ost2/bus0/target0/lun0/
Quoted 3 lines
=20
Also if lvm opens all known devices by way of/dev/whateverwhile scanning, it will only find existing devices there with devfs.Yeah, as long as devfs is running, that makes sense.
If you want a really robust solution, have your tool scan /proc/filesystems and see if devfs is available. If not, scan /proc/partitions. If devfs is available, then create a temporary mount point and mount it there, then scan $mntpoint/discs.
Regards, Richard.... Permanent: [email protected] Current: [email protected]