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
Helge Hafting wrote:
>
> 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?
>
> 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
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?
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
Glenn McGrath wrote:
> Helge Hafting wrote:
>
>> 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?
>>
>> 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
--
------------------------------------------------
Pierre Rousselet <[email protected]>
------------------------------------------------
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.
On Wed, Feb 28, 2001 at 09:29:24PM +1100, Glenn McGrath wrote:
> 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.
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.
--
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------------------------------------------
>>>>> " " == 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
On Thu, Mar 08, 2001 at 01:32:03PM +0100, Goswin Brederlow wrote:
> > 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.
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.
> 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.
Yeah, as long as devfs is running, that makes sense.
--
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------------------------------------------
AJ Lewis writes:
>
> --CblX+4bnyfN0pR09
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Thu, Mar 08, 2001 at 01:32:03PM +0100, Goswin Brederlow wrote:
> > > 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.
> >=20
> > First:
> >=20
> > % cat /proc/partitions=20
> > major minor #blocks name
> >=20
> > 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
> >=20
> > 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.
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.
> > 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=
> ost0/bus0/target0/lun0/
> > lr-xr-xr-x 1 root root 30 Jan 1 1970 disc1 -> ../ide/h=
> ost2/bus0/target0/lun0/
> >=20
> > Also if lvm opens all known devices by way of /dev/whatever while
> > 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]