Has anyone ever scripted a solution that returns on board hardware?

Chris_H

Chris_H

Apologies for the long title. But I couldn't think of a more concise version.
I've been meaning to cobble up something that say; grep(1)s all the hardware detected by the kernel (from /var/run/dmesg.boot), and returns the results in such a way, that it better facilitates the creation of a KERNCONF. But before I start, I was hoping that either 1) somebody had already done this (likely), or 2) that someone might have some thoughts on how I might best approach this -- Yes, I'll be sourcing /usr/src for hints. :)

Thanks!

--Chris
 
When I went to compile my first kernel on this laptop I used something similar to the following to get an idea of the hardware.

Converted from my simple csh(1) script to a sh(1) one liner:
for module in `awk '$1 == "device"' /usr/src/sys/amd64/conf/GENERIC | awk '{ print $2 }'`; do cat /var/run/dmesg.boot | awk '{print $1 }' | grep $module; done

Yeah, it can be prettied up a bit... but I'm ugly, and so is my code! :) (I don't use bourne shells much)
I'm sure 100 people have done the same thing 100 different ways, and this is not likely what you had in mind when you posted, but I thought it to be somewhat relevant.
 
wblock@ said:
I've just been thinking about that lately as a way to automate adding detail to the FreeBSD laptop wiki. See https://wiki.freebsd.org/Laptops/Dell_Latitude_E7240_i5-4310U for an example of the information to collect. It should also run usbconfig.
Click to expand...
Hah! Thanks, wblock@ ! For the life of me, I couldn't remember anything more than kldstat(8), and pciconf(8). I knew there were more, but didn't get the "see also" cross references I needed to find the other available tools. acpidump(8) being one of the ones I was trying to remember.
Prettying up the information, and transforming it into a usable fashion it the real trick, tho -- see my reply to Bethlehem for what I'm experimenting with now.
What brought me to finally attempting this, was that I was gifted an old Broadcom based pci wireless NIC. Pushing it in a slot, and booting one of my FreeBSD boxes, revealed no sign of it (unsupported?). Anyway, that's for another thread. ;)

Thanks for the reply, wblock@ !

--Chris
 
Bethlehem said:
When I went to compile my first kernel on this laptop I used something similar to the following to get an idea of the hardware.

Converted from my simple csh(1) script to a sh(1) one liner:
for module in `awk '$1 == "device"' /usr/src/sys/amd64/conf/GENERIC | awk '{ print $2 }'`; do cat /var/run/dmesg.boot | awk '{print $1 }' | grep $module; done

Yeah, it can be prettied up a bit... but I'm ugly, and so is my code! :) (I don't use bourne shells much)
I'm sure 100 people have done the same thing 100 different ways, and this is not likely what you had in mind when you posted, but I thought it to be somewhat relevant.
Click to expand...
Thanks for sharing that, Bethlehem .
I'm currently working in the same vane. I'm experimenting with assigning an array of devices/options provided in GENERIC, DEFAULT, NOTES, and PAE, eg;
Code: 
devices=apic cpufreq acpi eisa pci fdc ...
for name in $devices ...
and comparing against /var/run/dmesg.boot. This (dmesg.boot) is not a good strategy, given that it lists everything included in the kernel the box is running. But it made for a good exercise in returning useful results, in a usable form.
I'm going to attempt to use that knowledge gained, and apply it to results from tools in base, that better return actual hardware available, and in use (detected). :)

Thanks again, Bethlehem !

--Chris
 
It would be good to have 2 KERNCONFs, one that is automated, and another one for additional user customization, that includes the automated KERNCONF. The custom KERNCONF will take the strain off of developers, so they don't have to adjust for rare, custom, proprietary and constantly changing options.

Example based on wblock@ 's example:
Code: 
## This is the user edited KERNCONF that includes an automated KERNCONF

include AUTOMATED
nocpu   i486_CPU
ident   USERSUPPLEMENT
options  DEVICE_POLLING
options HZ=500

This example uses two KERNCONFs "AUTOMATED" and "USERSUPPLEMENT". Where "AUTOMATED" can be kept as simple as possible by using a hybrid way. "AUTOMATED" would work on basic options like motherboard hardware, basic hardware, common options, and toggling debugging options.
 
On a related note:
Will adding the following to src.conf(5), allow me to get the desired results, after hacking up a copy of GENERIC?
Code: 
nooptions  INVARIANTS
nooptions  INVARIANT_SUPPORT
nooptions  WITNESS
nooptions  WITNESS_SKIPSPIN
nooptions  DEADLKRES

Thanks!

--Chris
 
I'm confused by that. src.conf has a different format, and it's used for buildworld and not buildkernel, as far as I know. Are you trying to use that to build tools in the base to hack GENERIC?

Code: 
nooptions
variables typically go into different KERNCONFs like /sys/amd64/conf/CUSTOM.

src.conf has a format starting with
Code: 
WITH_
or
Code: 
WITHOUT_
, to build programs into the base of FreeBSD.
 
Right, sidetone .
Wishful thinking, on my part, I'm afraid.
I guess the best option to accomplish my intended goal, would be more along the lines of:
Code: 
# LIGHTKERN (remove unwanted bloat)

include MYCUSTOMKERN

ident  LIGHTKERN

nooptions  INVARIANTS
nooptions  INVARIANT_SUPPORT
nooptions  WITNESS
nooptions  WITNESS_SKIPSPIN
nooptions  DEADLKRES
Followed by:
Code: 
make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=LIGHTKERN

Thanks for the reply, sidetone !

--Chris
 
Quite true, and I was actually aware of that. But I like to keep things a bit more flux. Cause I have a tendency to experiment alot. :)

Thanks for taking the time to reply, sidetone !

--Chris
 
Maybe you were looking for
Code: 
makeoptions COPTFLAGS=""
in KERNCONF for kernel build arguments?


Ok, I found this on the previous page in the book.

These are for debug used in KERNCONF like what you had, except for nooptions.

Code: 
makeoptions DEBUG=-g
options KDB
options DDB
options INVARIANTS
options INVARIANTS_SUPPORT
options WITNESS
options WITNESS_SKIPSPIN
 
Last edited:
Maxnix said:
Chris_H you would give a look at this tool for OpenBSD ports.su/sysutils/dmassage too, pheraps.

HTH.
Click to expand...
Hello, Maxnix , and thanks for the reply.
Indeed. That looks promising. Appears that it's no longer maintained. I had to back in time (2011) to find it's web page. Maybe they moved, and didn't update the link. In any case, I'm going to give it a try. If it's as good as it appears at doing what's needed to create a custom kernel. Then I'll add it to the FreeBSD ports(7) tree. :)

Thanks again, Maxnix !
 
Hey, Warren, thanks!
I'll definitely take a look. Thanks for taking the time to give me it's location!
Given Perl is more my forté, I gave Maxnix' suggestion a try. As the code goes, it all looks good. But given it was written for OpenBSD, as apposed to FreeBSD, and given it hasn't been touched in 14 years. The results were pretty much, nadda. Before I give up on it, I'm going to spin up an OpenBSD Live, or Install CD/DVD (near that era) and note the differences -- device names, format(ting). I'm fairly confident upgrading (converting) it would be fairly trivial. If so, look for it in your nearest ports(7) tree. :)
Either way, I'll also have a look at your fine work. Maybe it's also a ports(7) target. :)

Thanks again, wblock@ !

--Chris
 
Thanks, Warren. I got impatient, and just went ahead, and visually compared output from dmesg(8), and a trimmed GENERIC. So once a new world, and kernel were in place. I went ahead, and installed dmidecode. The output, altho somewhat "generic", in some respects, does, none the less, look promising.
Thanks again, for the tip!

--Chris
 
You must log in or register to reply here.
Back
Top