Re: Re: scsi device names, symbolic names, devfs/sysfs

--llIrKcgUOe3dCx0c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 22, 2003 at 01:30:17PM -0400, Frank Edwards wrote:
> Devfs doesn't help.  What if the lun# changes?  Then the name of the
> drive changes.  Or what if the target id should change?
of course, but removing target3 won't affect target 4+...
removing a scsi disc in the classic dev system would move all discs
above it one letter down (sdc becomes sdb all of a sudden... and so
on), which can be _very_ confusing.

> No, the user should be given a way of autonomously naming their storage
> devices.  For example, imagine naming your floppies:  Quicken1,
> Quicken2, ScratchDisk, and so on.  Whenever you insert a floppy into the
> drive, it automounts it and allows one to use the name "Quicken1:" to
> access that drive.
yeah, that would be nice...=20

> <soapbox>
> IMNSHO, this should be the way every OS works.  I've only worked on
> AmigaDOS, PCDOS, and Unix-like systems (no experience with System36,
> OS/390, etc), but I can see no reason why it isn't done like this.  And
> the real killer is that the new approach is completely backward
> compatible.
>=20
> Notice how NO / NEVER / NONE hardware changes can affect this scheme.
> That's because the *USER* has assigned a *SYMBOLIC* name to a physical
> resource and the system conforms to the user, not the other way around.
> </soapbox>
mountpoints are also symbolic names assigned to devices, there's only
one capable administrator needed to keep them in order ;)

> Oh, and don't get too tied to devfs, as my understanding is that it
> becomes sysfs in 2.6.  Although the programming API stays very similar
> (devices still register via the register_devfs() function, for example),
> the user-level interface was supposed to change.  I haven't played with
> 2.6 yet (I don't have enough time to adequately play with 2.4!), but my
> understanding was that there was going to be a /sys and much of /proc
> was going to move there (except user processes, of course) and /dev was
> going to contain dynamic links to /sys.
everything in /proc not representing a currently running process should
BURN... it belongs into sysfs.

i thought devfs should be replaced by a userspace-managed implemen-
tation in the future... i don't think /sys is the correct location for
DEVices ;)

> I'm not the developer, though, so I really don't have a clue. :-)
me neither, it's all just a fake ;)
> Frank J. Edwards

fake
--=20
1024D/6238BB8F          Thomas Jakobi (fake) <[email protected]>
Fingerprint:            B80D AC08 9D30 6394 D5D4   1B9A 4DE3 7D52 6238 BB8F

--llIrKcgUOe3dCx0c
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/RpbBTeN9UmI4u48RApVxAKC2layQAFR/QxEv9KC8LKUe6eE3OQCeNYtj
lKWtyFOsJrUMtEcBwMtJXn0=
=5GHt
-----END PGP SIGNATURE-----

--llIrKcgUOe3dCx0c--