please no more intelagent solutions for this crap why not just sg.c.t.l where c
= controler 0..n, t = target 0..15 or 0..f, l = lun 0..n where max n = 7 prob i
dont want to limit it, the devices are created at boot time by the kernel as
there found. that way when u have multi bus, target, lun systems every thing
doesnt move, when u forget to turn one thinng on, or spend a half a day tring
to rescue ur system when u lose a hard drive. i hate that crap in bills world
too. u have a 3 disk system drive b fails, drive c becomes b, which doesnt have
the right partitions, then ur script does mkswap on sdb2, poof lunches what was
a nice data base. never happen u say. i guess u never have to use rescue disks
to edit ur fstab either, to get the system to boot. thats when u relise how big
vi is as a program.

so if nodes where created at boot time sd.c.t.l.p, scd.c.t.l, st.c.t.l,
sg.c.t.l and the program that did this could be run at a later time again. it
would solve all ur probleems, the one where u have sdb as a mo drive that u
forgot to put the platter in when the system booted, would stop u from using
narrow adx on wide drives to keep them from moving around. 

then u end up with a system like set serial, where i can write litttle sh script
and io adx 100 is ttyS1 and i dont care what any body else says, getty doesnt
start talking to my x10 controler turning apliances on/off as the issue mesage
and login prompt are displayed

this gives u all the absraction u need untill ur silly enough to implament scam
where all the scsi becomes plug n play, then u need a proggy to match well know
device names to the randomly assigned scsi ids, which is easy for disk drives if
u redefine the partion info to include volumme label info.

normaly i stay out of the religous wars on this list ie scsi/ide my controlers
better etc, but the current system sucks as bad as bills, and illl be damned if
i let to implament a worse one without bitching at least once

My opinions are my own and not that of my employer even if I am self employed
Tech Net, Inc.            --FREE THE MACHINES--                 651.224.2223
627 Palace Ave. #2                                         [EMAIL PROTECTED]
St. Paul, MN 55102-3517   part time  www.t-n-i.com           [EMAIL PROTECTED]
wanted    : adsl/cable modem with static ip at reasonable price
accept-txt: us-ascii,html,wordperfect7.0,6.x,5.x,rtf,msword6.0,2.x
accept-dat: ascii-delimited,paradox8.0,7.x,6.x,5.x,4.x,Dbase 4.0

On Sat, 13 Mar 1999, Bernard Hatt wrote:

>Matthias Andree wrote:
>> 
>> On Thu, Mar 11, 1999 at 10:58:00PM +0000, Bernard Hatt wrote:
>> > My two generated directories contain:
>> >
>> > bmh@nevermind]$ ls -l /proc/sg/type
>> > lr-xr-xr-x   1 root root  0 Mar 11 21:29 ARCHIVE_VIPER_150_21247 -> /dev/sgb
>> > lr-xr-xr-x   1 root root  0 Mar 11 21:29 IBM_DCAS-34330 -> /dev/sgc
>> 
>> What if I have two of them? We cannot have two inodes with the same
>> name. Append serial numbers of the drive, assuming that they are
>> different?
>
>Hmmm, yes, I should have thought more about this case, I'd assumed that
>in the case of duplicate devices, that the sg/addr/scsiX_idY would be
>used.
>
>There is also the case of two identical devices, with the same SCSI id
>on different controllers of the same type, to which I can't see a
>solution.
>
>Having thought more about my /proc/sg link solution there is a much more
>serious flaw - If my scanner is attached to /dev/sga and I set the
>permissions
>to allow anyone to use the scanner, then when the system is booted
>without
>the scanner, then anyone can send SCSI commands to my root disk.
>
>This could be fixed with boot time scripts to change the mode of all
>/dev/sg? devices to 0600, and then change /dev/type/UMAX_Astra_1220S
>to 0666 etc., but if you're going to do this you might as well generate
>the symbolic links at boot time from /proc/scsi/scsi.
>
>Still, if it wasn't for the flaws it would be a perfect solution :-)
>
>Bernard
>[EMAIL PROTECTED]
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>the body of a message to [EMAIL PROTECTED]
>


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Reply via email to