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



## Chris_H (May 20, 2016)

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


----------



## wblock@ (May 20, 2016)

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


----------



## Bethlehem (May 20, 2016)

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.


----------



## Chris_H (May 20, 2016)

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


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


----------



## Chris_H (May 20, 2016)

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


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;

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


----------



## coolhandluke (May 21, 2016)

Chris_H said:


> But before I start, I was hoping that either 1) somebody had already done this (likely), or  ...



Something like "lshw", perhaps?


----------



## wblock@ (May 21, 2016)

See sysutils/dmidecode, too.


----------



## Chris_H (May 21, 2016)

coolhandluke said:


> Something like "lshw", perhaps?


Thanks, coolhandluke .
That looks promising. But I'd likely need to translate Linux to *BSD kernel calls. _Still_, a worthy candidate -- thanks!

--Chris


----------



## Chris_H (May 21, 2016)

wblock@ said:


> See sysutils/dmidecode, too.


Thanks, Warren! I haven't built *anything* on this box yet. So I'm hoping to script up something quickly (initially). But otherwise, that looks like _just the ticket_. Thanks for taking the time to point it out!

--Chris


----------



## sidetone (May 21, 2016)

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:

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


----------



## Chris_H (May 21, 2016)

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?

```
nooptions  INVARIANTS
nooptions  INVARIANT_SUPPORT
nooptions  WITNESS
nooptions  WITNESS_SKIPSPIN
nooptions  DEADLKRES
```

Thanks!

--Chris


----------



## sidetone (May 21, 2016)

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?


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

src.conf has a format starting with 
	
	



```
WITH_
```
 or 
	
	



```
WITHOUT_
```
, to build programs into the base of FreeBSD.


----------



## Chris_H (May 21, 2016)

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:

```
# LIGHTKERN (remove unwanted bloat)

include MYCUSTOMKERN

ident  LIGHTKERN

nooptions  INVARIANTS
nooptions  INVARIANT_SUPPORT
nooptions  WITNESS
nooptions  WITNESS_SKIPSPIN
nooptions  DEADLKRES
```
Followed by:

```
make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=LIGHTKERN
```

Thanks for the reply, sidetone !

--Chris


----------



## sidetone (May 21, 2016)

You might want make.conf(5). You can set 
	
	



```
KERNCONF
```
 and 
	
	



```
ALWAYS_CHECK_MAKE
```
 from there.


----------



## Chris_H (May 21, 2016)

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


----------



## sidetone (May 21, 2016)

Maybe you were looking for 
	
	



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


```
makeoptions DEBUG=-g
options KDB
options DDB
options INVARIANTS
options INVARIANTS_SUPPORT
options WITNESS
options WITNESS_SKIPSPIN
```


----------



## Maxnix (May 21, 2016)

Chris_H you would give a look at this tool for OpenBSD ports.su/sysutils/dmassage too, pheraps.

HTH.


----------



## Chris_H (May 21, 2016)

Maxnix said:


> Chris_H you would give a look at this tool for OpenBSD ports.su/sysutils/dmassage too, pheraps.
> 
> HTH.


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 !


----------



## wblock@ (May 23, 2016)

My script is called notebookstats: http://www.wonkity.com/~wblock/notebookstats/.  It generates output formatted for the Moinmoin wiki currently used, but is still readable as text.


----------



## Chris_H (May 23, 2016)

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


----------



## wblock@ (May 24, 2016)

It could depend on sysutils/dmidecode, which can detect lots of things, possibly including machine model.


----------



## Chris_H (May 24, 2016)

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


----------



## tingo (May 26, 2016)

Something like inxi would be useful, but covers more than you asked for.


----------

