On Mon, 28 Sep 2009 16:05:12 -0700 (PDT) Albert Herranz <[email protected]> wrote:
>
> Are there any comments/objections to this patch?
>
Hi Albert,
I've had some more time to think about this, and I think I was overly
harsh when criticizing your initial approach to this. The type field
seems like a fairly reasonable way to extend the system (although the
spec does not say anything about how to deal with unknown types). I
would assume that there is some official registry for these types
though, to avoid conflicts...
Anyway, my ideal solution would be something like this:
- We start checking the type field in cistpl_funce. We already know
about types 0 and 1 (and now 4).
- We use this as a key for a subfunction, instead of the "func"
parameter. We'd still need to verify that a type 0 is only used in
the global CIS table, and a type 1 only in a local though.
- Any known good types are silently returned upwards, queued for the
function driver.
- Any unknown types emit a warning in dmesg, but do not abort the
init. This way we can have some kind of log if there is a parsing
bug, or a buggy card.
All of this might not be needed in an initial version, but this would
be the model that would make blissful. :)
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
signature.asc
Description: PGP signature
