lkml.org 
[lkml]   [1998]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Hacking ide.c for better pcmcia support...
Colin Plumb wrote:
..
> The problem is that if something ends up holding the mount open, then
> ide_unregister fails, and since it returns void, the failure goes unreported
> and the kernel ends up stuck in a bad state.
>
> The lack of umount -f is certainly a problem, but I'd also like unregister_ide
> to *do* something sensible if the device is busy.

Yeah, I noticed that too, but it is a user-bug, not a kernel-bug.

Nicer behaviour for PCMCIA CompactFlash-ATA devices would be
a useful thing for 2.3.xx. There is a CODE FREEZE on 2.1.xxx now.

The required solution is to parameterize the internal IDE timeouts
on a per-drive basis. That way, the pcmcia utilities could set the
timeouts to zero for CompactFlash-ATA-flash cards, but use different
values for CompactFlash-ATA-disk cards (like the IBM 230MB thingie).

With tiny timeouts for true flash memory, the zombie requests would
die rather rapidly, unlike today.

> One question: in the ide_drive_t structure, there are already 16 bits
> allocated in the bit-field range. (If FAKE_FDISK_FOR_EZDRIVE is
> set.) Should I just add another flag there? Is there a reason why
> the booleans before that are bytes and not bits?

The more frequently-accessed bools are bytes for faster-access,
the rest are bits to save memory. I was frugal about memory
at one time.. :)
--
mlord@pobox.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.093 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site