kenv - output needed

Andrew Thompson thompsa at FreeBSD.org
Tue Mar 23 19:20:46 UTC 2010


On Wed, Mar 24, 2010 at 08:06:23AM +1300, Atom Smasher wrote:
> On Wed, 24 Mar 2010, Andrew Thompson wrote:
> 
>> On Tue, Mar 23, 2010 at 05:12:47PM +1300, Atom Smasher wrote:
>>> i'm trying to figure out what might be reasonable output from kenv. on 
>>> the three machines that i have access to i'm already seeing wide 
>>> variations of formatting and usefulness.
>>> 
>>> i'd like to collect as much output as i can get (off-list should be fine) 
>>> from one of these two commands:
>>> 
>>> 1) preferred:
>>> 	kenv | egrep bios
>>> 
>>> 2) i can also use this:
>>> 	kenv | egrep 'product|maker'
>> 
>> kenv is essentially dumping all the variables set by the bootloader prior 
>> to starting the kernel. If you want something more structured then maybe 
>> the dmidecode utility would be useful.
> ===============
> 
> structure is cool, but it seems like you're being human-centric in your 
> reference to structure; i actually want to parse the info with a script, 
> making kenv preferable.
> 
> i want the ability to run the script without any privileges; again making 
> kenv preferable.
> 
> so with an unprivileged script, i'm leaning towards kenv to find out what 
> hardware is running (motherboard & system info, eg "Dell Inc., 0H603H, 
> PowerEdge 2950" or "Acer, Navarro, Aspire 5100").
> 
> other than being formatted more nicely (for humans, anyway) and only 
> running with root privileges, is there any ~real~ difference between the 
> information i would get from dmidecode rather than kenv (as it relates to 
> motherboard & system make & model)? it seems like in either case, i'm just 
> getting the info from smbios... and that info could be good, bad or ugly 
> regardless of how it's formatted.

Yea, both methods get the info from smbios. So back to the original
question about reasonable output from kenv, I would expect it to contain
all the same basic information that dmidecode fetches. If it is missing
something then it is a bug, otherwise that is the data the bios maker
has provided and the script will need to handle it.


cheers,
Andrew


More information about the freebsd-hackers mailing list