Date: Tue, 15 Dec 1998 21:14:37 -0800 (PST) From: dan@math.berkeley.edu (Dan Strick) To: grog@lemis.com Cc: dan@math.berkeley.edu, freebsd-current@FreeBSD.ORG Subject: Re: Tape Driver Changes Proposed: Tape Early Warning Behaviour Message-ID: <199812160514.VAA22429@math.berkeley.edu>
next in thread | raw e-mail | index | archive | help
> > One good reason for restricting the minor number format is that 16384 > > (i.e. 2^14) different entries for tape devices in /dev would be painful > > beyond belief. > > You wouldn't automatically create all device nodes, just those that > corresponded to real devices and their functions. There are too many of those, even for real devices. For example, the Archive viper 150 could write in 4 different "densities" and at two different speeds. When we throw in auto-rewind and auto-unload on close control, we need 32 different tape devices for which we cannot remember all the names. We might also need another 32 special files for the block devices. (Remember those? They have fallen out of favor and are not always implemented these days, but the concept is still valid.) In practice, we won't be able to have a different entry in /dev/MAKEDEV for each model of tape drive. We will have to use a single scsi tape entry that handles the worst case. The worst case should handle 8 densities, 4 speeds, 4 compression algorithms, auto-rewind, auto-unload, and any other such feature that we might want in the future (e.g. auto-double-eof-mark on close). That amounts to 1024 special files so far. If we were to follow this design philosophy to its logical conclusion, we would also have to specify the tape block size via minor device number (perhaps another 16 bits). > > > I claim that the idea of specifying tape drive operating parameters > > via minor device number was a really bad idea from almost the very > > beginning (unix v6 I believe) and should have been abandoned after > > the ioctl() system call became available. > > How would you tell tar to make a backup, this time only, which didn't > compress? If you did it with mt(1), how would you ensure that nobody > dicked with the settings between your running mt(1) and tar(1)? I would create a mechanism by which a tape drive had to be "allocated" to a particular user before the drive could be used. The allocation process would place the drive in a standard state. Only the user to whom the drive was allocated could change its settings. I implemented such a scheme about 20 years ago and it worked pretty well. There were some additional rules: 1) Any user could reallocate the drive to himself provided that the drive was not open, it didn't have any media loaded, and the current owner of the drive didn't have any processes running. 2) Root could do anything. 3) There is probably more that I don't remember. Implementation was almost trivial. Drive ownership was implemented by setting the owner/group of the special file(s). The program that did drive allocation was a very simple thing that ran setuid root. Dan Strick dan@math.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812160514.VAA22429>