Re: [MiNT] /dev/

[Michael Schwingen <rincewind@discworld.dascon.de>]

On Fri, May 07, 1999 at 06:55:52PM +0000, Jo Even Skarstein wrote:
> 
> MiNT does not "implement" the RSVF-cookie, it utilize the RSVF-drivers
> in it's own device-drivers if RSVF is present. RSVF implements (mostly)
> the same features as you'd expect from a device-driver, but as Mikko
> said, they're not entirely identical. MiNT handles these incompatibilities
> in it's device-drivers.

Um - please get the terms correct: there is no such thing as a RSVF driver.

The HSMODEM package consists of DRVIN.PRG (which installs the (X)BIOS and
GEMDOS extensions for OS's that don't have them), *and* several drivers,
each for a special kind of serial hardware.

The combination does install a RSVF cookie, which basically points to a list
of device entries, with name and BIOS device number for each device. The
single purpose of the RSVF cookie is to get a list of serial device names,
and to provide a mapping between GEMDOS device names and BIOS device
numbers. The RSVF cookie does *not* provide any API for accessing the ports.

To access the ports, you simply open u:\dev\portname, and use the defined
GEMDOS functions (ie. read/write/close and ioctl), which IIRC are at least
mostly MiNT-compatible.

> There's also a *huge* difference in how the API is implemented: With MiNT
> you simply use GEMDOS-calls, while HS-Modem functions are called through
> pointers in a structure pointed to by a cookie. Mikko says it implements
> u:\dev\ for serial-ports, I'm not sure what he means by that but it definitely
> does *not* mean that you can Fopen("u:\\dev\\modem2"..) under SingleTOS...

The cookie *may* contain a pointer to the driver-internal data structure as
passed to Dcntl, however, the documentation does not say that an application 
may use them to do I/O on the device. Furthermore, its presence is optional,
which makes the RSVF cookie basically a list of device names and BIOS device
numbers. The HSMODEM documentation states quite clearly that you have to use
GEMDOS functions on u:\dev\whatever to get the work done.

> I don't know how MagiC handles the RSVF-cookie, but I do know that it has
> device-drivers very similar to those in MiNT, and that it utilize HS-Modem
> in pretty much the same way.

Magic does nothing about the cookie itself, AFAIK. Magic might provide the
necessary Dsntl so that you don't need DRVIN but only the port-specific
drivers.

> I would definitely vote against introducing the RSVF-interface in the kernel,
> it's simply a very bad design. I suspect the reason it was introduced in the
> first place was because it was the only way to do it in TOS.

I agree that the design is not very clean, however, when implemented without
the Dcntl pointer, the cookie can't do any harm, either.

> As I said in another post here, the best solution would probably be to implement
> u:\dev\ in TOS as well, preferably through MetaDOS. This would make it a lot easier

DRVIN already does that - read the documentation (yes, it *is* available in
english as well).

> to write portable code, not to mention porting code from other platforms. Both
> MiNT and MagiC has real devices, not using them is a very bad move.

The interface to the port-specific drivers is clearly defined in the HSMODEM
documentation. If MiNT implemented this, we could simply use the drivers the
same way Magic does, without any need for DRVIN.

However, this still does not make the RSVF cookie unnecessary: existing
applications use it to get a list of available ports, so even if we decide
on a new method (which will only be available on MiNT), you will have to
update all those apps, and nevertheless provide RSVF for backwards
compatibility.

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen