lkml.org 
[lkml]   [1998]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
On Wed, 5 Aug 1998, Mike Jagdis wrote:

> On Tue, 4 Aug 1998, Ion Badulescu wrote:
>
> > Oh.. glad you brought this one up. I've asked this before, and I'm asking
> > again: who had the "brilliant" idea to change the ordering in enum scsi_inos
> > between 2.0 and 2.1??? Breaking compatibility just for the fun of it -- and
> > I mean literally. It buys us nothing and it breaks scsidev big time.
> >
> > I have a patch which I maintain locally for each machine using scsidev; all
> > it does is it changes the order back to the 2.0 one. I've submitted it in
> > the past and it got ignored... I'm willing to do it again, but I have a
> > feeling it's gonna have the same fate.
>
> If you are using scsidev why on earth do you care? Using scsidev you
> can assign names based on the manufacturer, model and serial number
> that SCSI devices return in response to INQUIRY commands. Forget
> host ids, channels, targets, luns and all that bollocks :-).
>
> I have a machine here, 7 disks, 6 in RAID groups using md, 3 SCSI
> controllers. The disks in /dev/md0 are /dev/scsi/md0-1 and
> /dev/scsi/md0-2. Similar for the other groups. I have merrily
> swapped drives between controllers and even swapped controllers
> for completely different types. Never a worry. Scsidev finds the
> disks where ever they are and gives them the right names.
>
> *This* is how device naming should work - devices have names based
> on *what* they are, not *where* they happen to be right now.

Perhaps so. It certainly makes sense to do it for metadevices drives,
since it pretty much eliminates the risk of assembling them in the wrong
order. But for regular disks it's just an extra hassle, an extra level of
indirection which buys me very little. Disks tend to move between
machines, *not* to change scsi id's or controllers on the same machine.
When I add a new disk to a host I have to care about chains and id's
anyway, so from there to the scsidev default naming convention is a very
quick transition.

Anyway, the above is just a matter of taste and convenience. My point was
that the gratuitous ordering change in 2.1 vs. 2.0 breaks compatibility
for absolutely no good reason.

> (I did, however, change scsidev to handle backslashed end of lines
> and to have an option to generate an initial scsi.alias. I'll dig
> the changes out and release them sometime if someone reminds me
> at frequent intervals :-) )

Do you have a fix for the serial number stuff too? :-) I haven't looked
into it, since I don't use it, but I tried it just now on a couple of
machines (both 2.0 and 2.1) and scsidev -s prints "(null)" for every
device. Another thing I fixed a while ago was support for more than 8
disks -- the stock version wasn't scanning minors > 127.


Ion

--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.


-
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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.072 / U:20.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site