Re: Driver Update Disk discussion

From: Peter Jeremy (PeterJeremy_at_optushome.com.au)
Date: 02/25/05

  • Next message: Danny Braniss: "iSCSI initiator driver beta version, testers wanted" 
    Date: Fri, 25 Feb 2005 20:39:17 +1100
To: Scott Long <scottl@samsco.org>

    On Thu, 2005-Feb-24 17:59:19 -0700, Scott Long wrote:
    >- kernel option support. How do we support vendor modules in a kernel
    >that might be compiled with PAE (rather common these days), SMP, MAC,
    >etc. The loader and /boot infrastructure has no concept of this. It's
    >highly important, though.

    AFAIK, PAE is only relevant on iA32. I second the suggestion that PAE
    be treated as a distinct architecture for these purposes.

    INVARIANTS and WITNESS are the other options that impact ABI. These
    are probably unnecessary on -RELEASE but it would be nice if people
    could build a kernel with WITNESS and not have it panic if they loaded
    a module that wasn't compiled with WITNESS (which I think it the
    current behaviour).

    >- kernel api/abi. We are trying to keep the kernel api/abi stable now,
    ...
    >don't have the right hash. Should we follow with something similar, or
    >should we have runtime checks that check symbol/structure signatures?

    It would be wonderful if we could have a mechanism that did load-time
    validation that the module was compatible with the kernel. Unfortunately,
    I don't think there's any sane way to verify data structure compatability.
    (Verifying function call APIs is reasonably easy). Run-time checking adds
    overheads which may be significant for commonly used interfaces.

    >Or should we say that we make no guarantees about a binary-only module
    >working on anything but a -RELEASE kernel?

    At the very least we need to support errata branches. The RE team has
    expended a lot of effort to provide a mechanism to handle critical
    problems found post-release. We don't want to negate this by telling
    users that they have a choice of either using driver X or fixing hole Y.

    Unfortunately, in the rare case where an errata fix affects a kernel
    API/ABI, the change is probably critical to fixing the problem. This
    would require the FreeBSD fix to be co-ordinated with the driver vendor.

    I think that guaranteeing operation in -STABLE is probably impractical -
    though API/ABI changes would need to be flagged to vendors so they could
    test drivers for the next FreeBSD release. 

    -- 
Peter Jeremy
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Danny Braniss: "iSCSI initiator driver beta version, testers wanted"

    Relevant Pages