Linux-kernel mailing list archive 1998-31,: Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

# Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Fri, 7 Aug 1998 13:53:14 +1000

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Anthony Barbachan: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Previous message: Anthony Barbachan: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"

Terry L. Ridder writes:
> Hello Everyone;
>
> Some dev_fs's cheerleaders are attributing abilities to dev_fs
> which do not exist.

And vice versa.

> >From the updated dev_fs FAQ.
>
> <Begin Quote>
> SCSI Host Probing Issues
> <section>
> ========================
>
> <snip>
>
> Note that this scheme does not address the SCSI host order if you have
> multiple cards of the same type (such as NCR53c8xx). In this case you
> need to use the driver-specific boot parameters to control this.
> <End Quote>
>
> If you add a new SCSI controller to a system it is totally up to you
> to tell the kernel what order to probe the SCSI hosts. If you do not
> and you are using dev_fs /dev/sd/c0t3d0s1 and the SCSI host probing
> finds your new SCSI controller first you are out of luck. Because
> /dev/sd/c0t3d0s1 is no longer what you has before adding the new
> SCSI controller.
>
> So all these arguments that dev_fs "saves" you from the current
> SCSI rearranging are false. You still have to deal with the order
> in which SCSI hosts are probe.

Incorrect. If you don't open your box and fiddle your controllers, you
are safe from SCSI rearranging. By far the most common operation is
that a SCSI device is removed/inserted. Moving controllers around is
far less common.
A typical situtation is where you have just one controller, but
devices are from time to time removed/inserted.
The single controller situtation would constitute the bulk of SCSI
systems.

>
> Stephen Frost wrote:
> >
> > > I do not know about it similarity to other UNIX's (other than SUN/SCO) but
> > > /dev/sda is definately simple. As far a company goes they are not going to
> > > care if their drive is named /dev/sda or /dev/dsk/sd/c0t0d0u0 (whatever).
>
> But they do.

Perhaps the ones you talk to do. Other don't care about the new names,
or are enthusiastic.

ObMantra: no-one is forcing you to use the new names.

> > I've got another machine w/ 5 SCSI controller in it, of which
> > only 4 are used and I've got a total of 30 disks, this system is running
> > a nice big Oracle system. Oracle at least in the past for me does NOT
> > like it when/if the name it uses to access a drive changes. If you are
> > using raw disk mode then in my view you basically HAVE to have something
> > like /dev/rdsk/c0t0d0s0. You could set the database up using /dev/sda,
> > but if you ever changed your configuration, oracle would probably die
> > and you'd probably lose any data stored on any disks that had their name
> > changed.
>
> Please see above concerning SCSI host probing. Even under dev_fs if
> SCSI host probing order changes controller numbers will change, and
> Oracle would have the same problems.

Physically moving controllers around is far less likely. Furthermore,
the devfs FAQ is quite up-front about it: I have not attempted to hide
the issue.

> > My only concern about devfs would be how it assigns controller
> > number, I like some of the things about how SUN does it, like that the
> > controller number basically never changes unless you do some strange
> > stuff, is this true for devfs?
> >
>
> Please see above. You add a new controller it is up to you to
> indicate what the SCSI host probing order should be. Dev_fs has
> nothing to do with this. If you do not indicate what the SCSI host
> probing order should be the controller number can change.

Please see above. Fiddling your controllers is much rarer. Therefore
the common case of removing/inserting devices is greatly helped.

> > Except that from what I understand it doesn't break backwards
> > compatibility at all. EIDE I agree works okay the way it is w/ /dev/hda,
> > but that's mainly because it's consistent and the /dev/hda access point
> > doesn't change if you add or remove disks, it's directly associated w/
> > controller 0, master drive. Floppy drives are /dev/fd0, closer in my view
> > to devfs already than /dev/sda is.
>
> It does break backward compatibility in a sense.
> As Theodore has pointed out in several postings which I quote below:
>
> <Begin Quote>
> Precisely. In Unix we have a very well developed abstraction for saving
> this kind of state: permissions, user/group ownership, modtimes, etc.
> It's called a filesystem. Tar is an unmitigated hack; using a C program
> helps hide the fact that what you're doing is a hack, but it's still a
> hack.
> <End Quote>

And as I have said, if there is sufficient demand, I can add
persistence to devfs itself. This is a side issue to the basic concept
of devfs.

> > Thinking technically, since when does someone use a letter as a
> > counter? You going to use a char in a for loop for your counter or an
> > int? For some very specific things where you want to say list off the
> > ascii character set you might do that, but I know I use an int when I'm
> > in need of a counter.
>
> What are you talking about?
> Please show me where in any of the kernel scsi code where a letter is
> being used for a counter.

drivers/scsi/sd.c: sd_devname()

> <snip>
>
> > Another issue, what happenes when a drive doesn't respond to
> > SCSI probes? Happens all too often to me, and figuring out which drive
> > died would be MUCH harder to do w/ /dev/sda than w/ /dev/c0t0d0s0, not
> > impossible, but would certainly take a whole lot more time.

Conveniently ignored, I note. He raises a valid point.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

- Next message: Anthony Barbachan: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Previous message: Anthony Barbachan: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"