On Wed 16 July 2003 16:19, Joerg Schilling wrote: > From [EMAIL PROTECTED] Wed Jul 16 15:36:51 2003 > > >> Linus Torvalds usually blocks them :-( > > > >May I make a suggestion? Joerg! Next time you feel like claiming > > that Linus Torvalds (or anybody else in person, Alan Cox > > maybe?) is so to say sitting around and deliberately tries to > > complicate your life as cdrecord developer, then I suggest to > > take a deep breath and abstain from such remarks. Not that they > > are simply not true, such comments are generally inappropriate > > for essentially technical forum such as this. If you want to > > criticize, criticize technologies and their implementations, > > but not persons. If personal comment is unavoidable, explicitly > > address the person in question. Same naturally applies to all > > subscribers to this forum. A. > > First: it is Linus who started to be personal against me, so he > obviously likes this way of discussion....
I don't read lkml normally but in the thread you link below he uses your name as an example of someone writing a userspace tool. Perhaps you are simply the most famous/vocal user space programmer to deal with that code? I bet if you asked a random person to name a Linux kernel hacker then Linus and Alan would probably be mentioned more often than others as well... > Second: I was not critizising the person but the doings. <snip> > Let me make an example: A few weeks ago, Jeff Garzik announced a > new SCSI interface for ATAPI. > > http://marc.theaimsgroup.com/?t=105392536100002&r=3&w=2 > > If you read this thread, you see that Linus obviously does not > understand the background and likes the implementation to be > better than anything before, before giving Jeff a chance. As it > should be obvious that a draft of a new implementation method > never is made complete just in order to save time, a > knowledgeable programmer would be able to understand whether a > new idea could give problems in the future. I think you and Linus are really looking at the whole thing from exactly opposite directions. You're thinking that it's all really SCSI commands that are being sent over SCSI- or non-SCSI connections. So, just write a generic SCSI kernel interface and have the kernel patch things up where it's not quite SCSI, then have cdrecord shove appropriate SCSI commands through that interface to the drive, and be done with it. So you're looking at the similarities. Linus on the other hand seems to be looking at the differences. All these different interfaces look like SCSI because they use the SCSI command set. But on other parts they're pretty different, for example because they use different connections. If you're going to map things arbitrarily (which ide-scsi is doing now, hence J�rgs complaints about unstable devices->busses mapping in Linux) anyway, then why emulate a SCSI bus if you haven't got one? Wouldn't it be silly if the kernel told userspace that I had a SCSI device on the first SCSI bus and a SCSI device on the second SCSI bus, while in reality they're both ATAPI devices on different controllers and I haven't even got a SCSI host adapter let alone any drives? So instead he wants a generic /dev/driveX and /dev/cdromX etc., because it makes more sense for the end user and you have to map things in the kernel anyway. Ofcourse, the problem for cdrecord then becomes that its IO model is based around SCSI, including SCSI attachment bus/id/lun addressing. Which is fine on everything but Linux apparently. I think I know why too. UNIX has traditionally been used on large machines, servers and mainframes, not on consumer-grade PCs. Those big machines don't have IDE. The low end has SCSI, and maybe the high end too I don't know, but at least it's not IDE. So, everything is designed around SCSI. Now what do you do when you want to run Solaris or BSD on x86 and you need to support ATAPI? Right, you look at it as SCSI with a different bus, and put it within your existing SCSI framework. Linux in the mean time was designed from the beginning for PCs with IDE/ATAPI drives and SCSI drives, so it had a generic block IO layer and underneath this layer two separate IDE and SCSI subsystems. Which ofcourse caused problems when CD writers showed up, which led to the ide-scsi ATAPI support hack. And now they're reworking things, but at the top level they still have their own block layer as the userspace interface, instead of mapping everything to the SCSI model as other OSes apparently do. So yes, Linux does do things differently from everything that's been used before. Linus actually gives the reason for that in http://marc.theaimsgroup.com/?l=linux-kernel&m=105401713912746&w=2 I don't see why Linux would have to do everything exactly like other unices. It's designed for different systems, systems on which other approaches may make more sense. Dismissing something outright because it differs from what has already been done seems to me to be an awfully limited way of engineering. Make any sense? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
