Re: CD writing in future Linux (stirring up a hornets' nest)

[Martin Mares <mj@ucw.cz>]

Hello Jörg!

> It seems that you missunderstand this. No operating system uses file names
> internally.

That's right. OS kernels usually use pointers for that, which are surely
not a reasonable user-space API. On Linux, the user-space API is to address
devices by their names.

> OS instead typically handle SCSI devices that are not connected
> via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system
> by asuming they are all on separate SCSI busses that only have one single drive 
> conected each.
> 
> What Linux does is to artificially prevent this view to been seen from outside the
> Linux kernel, or to avoid integrating a particular device into a unique SCSI
> driver system although it would be apropriate.

How exactly does Linux prevent this???

The devices _are_ integrated in a single driver system, at least from the user-space
point of view. You can call open() on the device name and then send the appropriate
ioctl's. The device names are just strings you shouldn't assume anything about.

Feel free to imagine that every device is on its own bus, nothing in the
kernel steps in your way.

> Users like to be able to get a list of posible targets for a single protocol.
> Nobody would ever think about trying to prevent people from getting a unified
> view on the list possible hosts that talk TCP/IP.

How do you perform -scanbus for TCP/IP? :-)

> In addition, nobody would ever think about implementing a separate TCP/IP stack 
> for network interfaces that are PPP connections via a modem vs. network 
> interfaces that go via a Ethernet adaptor. Nobody would ever try to convince
> me that you could save code in the kernel by avoiding the usual network stack 
> as a specific machine may not have Ethernet but a Modem connection only.

There is an interesting similarity: in the TCP/IP stack, you also shouldn't
assume anything about names of network interfaces, they are just opaque
identifiers (in many times assigned by the administrator, not by the kernel).
The right way of addressing is by IP addresses or DNS names, which is
pretty similar to the addressing of SCSI devices on Linux, isn't it?

> If the Linux folks could give technical based explanations for the questions 
> from above and if they would create a new completely orthogonal view on SCSI [*]
> I had no problem. But up to now, the only answer was: "We do it this 
> way because we do it this way". 

We do it this way, because we see no sense in fabricating virtual SCSI
buses, which do not exist in reality.

Also, I don't see a single reason why should I refer to my CD drive by
different names depending on whether I am mounting a CDROM and if I am
burning a CD. The device is still the same and so should be its name.

Scanning for all available CD burners is of course a nice feature, but
I don't think it should be implemented by asking all existing SCSI-like
devices if they are a CD burner (for example because there can be an
almost infinite number of them, given that you can do SCSI-over-IP
and other similar tricks). The problem of presenting devices to the
users is in no way limited to CD burners or SCSI devices, it's a general
problem and I think we should try to find a complete solution. However,
the approach libscg uses is clearly not applicable to other domains.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/