Re: Fcntl() modification proposal

[Eddy Morfan <morfan@etu.info.unicaen.fr>]

> That's just a documentation issue. I've started a list of Fcntl opcodes in
> use (see ftp://ftp.uni-muenster.de/pub/atari/docs/)
> 

> That's just a documentation issue. I've started a list of Fcntl opcodes in
> use (see ftp://ftp.uni-muenster.de/pub/atari/docs/)
> 

I think you've done a mistake (or maybe is it me ?). Your documentation lists
both Dcntl() and Fcntl() opcodes together, but they are very different and are 
used separetely. In all documentation found, Dcntl() opcodes are reported to be
file systems specific commands and thus the file system creator is free to make
watever he wants. Dcntl() commands are sent directly to the file system driver
(to its fsctnl() function) and are sent to the device driver. As they are file
system specific, no opcode conflict is possible, so a documentation will
only be used to know the filestem specific functions.
The Fcntl() call is different as some opcodes have to be supported by all
device drivers and the system defines opcodes specific to each kind of file.
The fcntl() opcodes which aren't handled by the system are passed to the device
driver (to its ioctl() function) but the system never call a filesystem driver.
I'm sure of this facts as I took a look at the MiNT source to check.
This is false only when a filesystem driver and a device driver share the same
opcodes, but its only a programmer choice and is not legal as fcntl() opcodes
aren't free to use (unlike the Dcntl() ones).

So the only problem is the choice of the fcntl() opcodes.

A list is ok for the mew standard fcntl opcodes, but how would a programmer
know that the opcodes he choose won't be used later for new standard Fcntl()
commands ?
That's why I think there should be a number of opcodes reserved for programmer's
use in order to avoid anarchic opcodes use.
As an example, nobody knows if the opcodes used by the audiodev (wich are
private opcodes) won't be used for different standard opcodes. (We can't be sure
that there will never have, and it isn't written in any doc that the remaining
fcntl() opcodes are free and will never be used by the kernel.).
So, wouldn't it be simplier to make this choice now.
Please answer me and explain what my mistake is (if I am wrong).
Eddy.