There exists a patch for adding a mode to our floppy driver to
add DEC RX50 media handling.
The crucial part of this is the addition of this line:
{ 10,2,0xFF,0x10,80, 800,1,FDC_300KBPS,1,0x2E,1 }, /* 400K DEC RX50 */
But if one examines the fd.c driver, one cannot help but notice that the
handling of densities is a bit convoluted, to put it mildly.
I'm looking for a volounteer to do this, it is a quite simple job and
I am quite sure that practically everybody has the hardware they need to
do this :-)
Cleaning it up consists of the following steps:
1. Define a new set of (bitmap) macros to distinguish the drive type:
#define FD_3S 0x0001 /* 3.5" single density */
#define FD_5S 0x0002 /* 5.25" single density */
...
And use these instead of the FD_1200 and similar in
struct fd_data->type.
2. Augment the struct fd_type with two new fields:
int minor; /* minor device encoding */
int drives; /* bitmap of compatible drives (FD_[35][SD]) */
And fill these fields out in the fd_types[NUMTYPES] array.
Add a termination entry at the end of the table so the
NUMTYPES, NUMDENS, and FD_%d[5_25] #defines can be eliminated.
3. Change the _clone code to use the new "minor" field instead of
the private table it uses now. (Eliminate and avoid any
use of NUMTYPES, NUMDENS and FD_%d[5_25]).
4. Change the code in Fdopen to examine the "drives" field in the
fd_types[] array instead of the hardcoded switch. (Eliminate
and avoid any use of NUMTYPES, NUMDENS and and FD_%d[5_25]);
5. Remove any other use of NUMTYPES, NUMDENS and FD_%d[5_25]
6. Add the "rx50" entry from above to the table to show how simple
that is now.
7. Make it possible to define a new mode from userland with an ioctl.
(hint: instead of the index, put a pointer to the struct fd_type into
the fd_data structure.)
Preferably, send one patch per step rather than one huge patch since that
will make reviewing easier.
First volounteer to send me email gets the assignment.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
