Did you make any progress on this Andrew ?
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes: >In message <[EMAIL PROTECTED]>, "And >rew R. Reiter" writes: >> >>Someone already doing this? If not, I'm down. > >You won, you're the first one in my inbox :-) > >Ready ? > >Steady ? > >Start! > >:-) > >> >>On Tue, 11 Dec 2001, Poul-Henning Kamp wrote: >> >>: >>: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 >>: >> >>-- >>Andrew R. Reiter >>[EMAIL PROTECTED] >>[EMAIL PROTECTED] >> >> > >-- >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 > -- 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
