In message <[EMAIL PROTECTED]> Mike Meyer writes:
: You may well be right, and there are good technical reasons for not
: doing this. The only real reason that's been presented for not doing
: MMC is that all the non-MMC drives might cause a support
: headache. There are sound technical reasons for *not* doing non-MMC
: drives, and Ken and I agree on that.

Actually, the real reason is that MMC drives that mostly support the
standard, but do it wrong in ways that are hard to detect.  Those are
going to be the worst to try to support.  There are some drives out
there that just hang when you issue them certain MMC commands, as an
example.  They shouldn't but they do and you have to be careful not to 
send them these commands.

: If the answer from the person who would have to approve the code had
: come back "Ok, provide the code and we'll see how well it works in
: practice", I'd do the code. But when it appears the code would never
: make it into the tree to be used, why waste my time?

I think that you overstate ken's reluctance.  If you can come up with
a good way to deal with this and have a good error mechanism for those 
drives that don't support this then I think he might (and I repeat
might) be talked into it.  I've found Ken quite accepting of code in
the past when I've gone to the trouble of doing something.

I've found in the past that working code has a way of making people
reconsider their opinions of things.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to