Re: [Freedos-32-dev] Driver interface: a proposal

[Salvo I. <sa...@it...>]

Hello,

> I think that we can use some ``non crazy'' naming scheme for the
> devices (BTW, I like the GRUB naming: first floppy = (fd0), second
> floppy = (fd1), first hd = (hd0), first partition on the
> first hd = (hd0, 0), and so on...), allowing the kernel to create
> appropriate alias names (A:, B:, C:, and so on) in order to preserve
> compatibility with old DOS applications.

Yes, this is the idea. But (fd0) is a block device or a file system device?
And A? BTW, the colon (':') is not really part of the drive name under
DOS... I know this could be a little confusing. I remember that DOS
translates drive letters to drive numbers, that are managed by block device
drivers. In my past proposal, (fd0) was the block device, and A the file
system device.

Only, I suggest the Linux naming for such devices, it seems to me more
concise, like hda1 instead of (hd0, 0). Moreover ',' is an invalid character
for a DOS file name in 8.3 format, but this is not really important since we
use the long name format. On the other hand, GRUB is actually used to boot
FD32... I don't know.

> Using your approach, the
> FAT driver will add a FS interface to (hd0,0) --- using a different
> approach, it can simply notify the kernel that (hd0,0) is hosting a
> FAT FS... This is basically the same thing, only the implementation
> changes.
> At this point, the kernel sees that there is 1 FS interface, and
> associates the alias name C: to it.

This is correct, but how do you export the FS interface to the kernel?
I've imagined two ways: using a separate device, or using the same device.
Of course I'd like to ear more, those are only my suggestions.

> Ok... So, if I understand it correctly, the problem is ``how should we
> implement name aliases without introducing an alias device in the list?''

Plus or minus (!)...
Referring to my proposals again: with the first idea the file system device
is a device like all the others, not an alias, and alias are provided for
ASSIGN, SUBST and JOIN features by the file system layer of the kernel; with
the second idea aliases are provided as above, but drive letters are
considered aliases for the block devices names. So they are not "alias
devices", but "alias names for file system devices", implemented at FS
level. Perhaps we need alias for devices, too? With your idea, "implement
name aliases" for what?

[Character devices]
> Well... I don't know the DOS FS internals very well, but... This is
> the simplest thing that I can think about:
> - each file is identified by the kernel through a numeric handle;
> - a table (the JFT?) is used by the kernel to associate a device (and
>   hence a driver) and a driver private data structure (an SFT entry?) to
>   the numeric handle
> - the kernel calls the write/read functions from the device structure that
>   is in the JFT entry. (By default, entry number 1 will contain pointers
> to the console output functions)
> This is everything that must be implemented in the kernel; all the
> other actions are performed by the driver.

AFAIK, when a FS open is issued, DOS first check if the file name is the
name of a valid character device. If it is, DOS uses the character device
driver, otherwise it uses the file system functions. I think this could be
valid for console devices too.

Moreover, under DOS you have two ways to specify character devices file
names:
- a file name that matches with a character device name is considered to
refer to the device; this is valid also if any path if specified, and the
path must be existent
- unless the path is "\dev\<filename>" (with any drive specification, too):
even if no "dev" directory is present in the root directory, DOS will refer
to that device. Note that you must say "\dev\<filename>", while if you
specify "dev\<filename>" the DOS call will fail even if you are in the root
directory. For this reason I suppose this kind of names are resolved before
the name is canonicalized with "truename".

An idea could be: we have three character devices, named stdin, stdout and
stderr. When an application is run, FD32 will open these three files on
handles 0, 1 and 2. This is done in order to give to all character device
the same treatment.

Anyway, it seems to me that DOS doens't have such devices, but only exports
a CON device to applications, that is used as stdout when writing and as
stdin when reading. I don't know about the lack of a "true" stderr device,
and don't know if our stderr is only a DJGPP hack, nor if is DJGPP which
opens the streams 0, 1 and 2 you have said. Do you have more informations
about that? It could also be interesting looking at the FreeDOS kernel.

> >I don't know if reset destroys system memory. Perhaps this depend on the
> >BIOS: I think when the memory check is enabled, it performs a write
> >check, so we lose our data; this has to be tested.
> I hoped that it only performed the write test on some memory
> locations, not all... Anyway, the BIOS should have a configuration
> option called ``fast boot'', or ``fast memory test'', or similar :)

In fact I've said "*when* memory check is enabled"... ;-)
If this kind of logging features is for us only, I don't see any problem,
provided that it really works.

BTW, booting FD32 I see that the memory informations are displayed two
times, with slightly different values. Is this normal? Why does this happen?

> (I am getting crazy with all the possible kinds of abbreviations in
> order not to scroll the debug messages out of the screen)

:-)
Ok, I'll try to code it today, when I'm bored to study economics (oral exams
start Friday... perhaps this is the right time to pass it!).

> ...and... Salvo, ``in the mouth of the wolf'' for your exam!!!

I've some doubt of the meaning of this sentence outside Italy! ;-)
However, thank you very much.

Bye,
Salvo/Sampled Sensations
E-mail: salvo AT sampsens.cjb.net
Sampled Sensations - digital music : http://www.sampsens.cjb.net
FreeDOS 32 - the 32-bit DOS        : http://freedos-32.sourceforge.net
PGP Key Fingerprint: 5991 4C97 D4D8 0B3D BA43  5398 BE9F 07E8 4CD2 1042