[lkml]   [2008]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH][resubmit] HP iLO driver
    On Mon 2008-07-07 17:37:18, Altobelli, David wrote:
    > Pavel Machek wrote:
    > > Hi!
    > >
    > >>>> A driver for the HP iLO/iLO2 management processor, which allows
    > >>>> userspace programs to query the management processor. Programs can
    > >>>> open a channel to the device (/dev/hpilo/dXccbN), and use this to
    > >>>> send/receive queries.
    > >>>
    > >>> What kind of queries? Is there documentation somewhere?
    > >>
    > >> Generally, it can get data out of the management processor - things
    > >> like basic iLO configuration (users, nic, etc), handle SNMP traffic,
    > >> flashing iLO, and some others.
    > >>
    > >> Unfortunately, there isn't yet any available documenation.
    > >
    > > Ok, I guess we should have documentation "what does it do" and "what
    > > protocol does it speak" before we can think about merging.
    > I really hope that isn't the case.

    Telling us "what does it do" seems like good start.

    > However, I do think there is value in merging the driver without docs.
    > Having drivers in tree is often stated as a goal, because of the obvious
    > security and API/ABI disadvantages to out of tree drivers.

    You know, we'd prefer to have kernel<->user ABI documented. With this
    driver... we don't.

    What does /dev/hpilo/* do? Beep speakers? Control fans? Launch atomic
    bombs? What will happen on cat /bin/bash > /dev/hpilo/dXccbN? Does
    that depend on concrete machine? Is it acceptable for this
    functionality not to be abstracted out? (Kernel should provide hw
    abstraction, right?)

    > If this can't be merged, then we continue to ship an out of tree driver,
    > which no one (us, distros, customers) likes. We pester our partners to
    > support this driver, or include it, or what have you. We get slowly
    > out of date, and bugs creep in, or our package breaks on upstream kernels.
    > To me, it seems like merging the driver is the better path.

    Docs for kernel<->user ABI does not seem like too much to ask.

    If you wrote a driver, I don't think it is unreasonable for me to ask
    "how to use that driver".
    (cesky, pictures)

     \ /
      Last update: 2008-07-08 09:23    [W:0.022 / U:5.328 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site