lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0807072127390.12950@asgard.lang.hm>
Date:	Mon, 7 Jul 2008 21:41:41 -0700 (PDT)
From:	david@...g.hm
To:	"Altobelli, David" <david.altobelli@...com>
cc:	Pavel Machek <pavel@...e.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"greg@...ah.com" <greg@...ah.com>
Subject: RE: [PATCH][resubmit] HP iLO driver

On Mon, 7 Jul 2008, 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.
>
> The message packets and documention are owned by hardware teams,
> and they currently do not want to make that documentation public.

umm, by merging the code a you reveal a lot of what they are attempting to 
keep secret. what's to stop someone from reading the code and writing the 
documentation?

that really should be someone at HP if you don't want to publish the 
exising documentation (since you are submitting the code)

> 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.
>
> 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.

correct, it's a far better path for you and your users, but it gets even 
better if there is some documentation to go with it.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ