Re: Device probing and driver attach

[Joerg Sonnenberger]

On Fri, Nov 03, 2017 at 07:46:04PM +0100, Rocky Hotas wrote:
> - In principle, if one built a custom kernel including *only* the drivers
> needed by its current machine, would the boot time get significantly
> reduced?

Well, assuming any modernish bus with decent device enumeration
functionality, the answer is pretty much "it doesn't matter". Most of
the probe functions match things like bus/vendor IDs against a table.
There are very few PCI devices that are more involved like checking the
PCI config space (i.e. rtk vs re) and require many additional cycles. So
even with a thousand probe functions run with one microsecond teach, we
are talking about < 1 milli second per device. Given that the actual
hardware configuration often contains delay loops, probing simply doesn't
matter.

> - When a BIOS does not perform this operation, is during the
> autoconfiguration that device BARs are written by the OS?

There are two different parts here:
(1) Probing the size of a PCI BAR. This is done by the OS for general
accounting.
(2) Reserving and/or assigning space for devices. This is generally
assumptions on x86 and many other platforms to be handled by the
firmware, with some fallback code i.e. for hot plugging bridges.

Joerg

Device probing and driver attach

[Rocky Hotas]

Hi all!
I hope this is appropriate to this list.
When the OS is booted, it still doesn't know the devices that will be
present in the current machine and it doesn't then know what drivers
should be used. After the bootstrap, the system autoconfiguration is
performed: according to autoconf(9), "Autoconfiguration is the process
of matching hardware devices with an appropriate device driver". Here
follow some questions:
- For each detected device, the probe function of *any* driver is called?
It seems a cumbersome procedure, but boot time is not that much long.
- In principle, if one built a custom kernel including *only* the drivers
needed by its current machine, would the boot time get significantly
reduced?
- When a BIOS does not perform this operation, is during the
autoconfiguration that device BARs are written by the OS?
- autoconf(9) specifies that "The autoconfiguration framework itself is
implemented within the file sys/kern/subr_autoconf.c". I am not that
skilled with it: which is, in that file, the routine that searches for
new devices and calls driver probe functions?
Thanks to anyone who can answer to even just one... or half :) of the
questions.

Rocky

Re: ext3 support

[Abhirup Das]

Just curious what is missing from the google summer of code work that you 
linked in your email. Why hasn't that been merged into the main repository?


From: tech-kern-ow...@netbsd.org  on behalf of 
Christos Zoulas 
Sent: October 29, 2017 2:39:05 PM
To: tech-kern@netbsd.org
Subject: Re: ext3 support

In article 
,
Abhirup Das   wrote:
>Hi,
>
>I just came across the ext3 implementation project listed on the netbsd
>website, https://wiki.netbsd.org/projects/project/ext3fs/
>and I would like to take the time to implement this. But I am not too
>sure on how to start this project, I have read up on journaling and I
>understand the added work that journaling needs to perform.
>However I am sure ext3 needs more than just journaling, but I havent
>come across a specifications list for ext3 yet. Any advice on how to
>start this project would be greatly appreciated.

So this is a bit complicated issue. I am not sure if adding journaling
support is worth it (compared to the amount of time it will take to
implement it) because you can always mount the filesystem on linux,
recover from the journal and then use it on NetBSD. OTOH there has
been some ext3/ext4 work done as part of GSoC 2016...

https://summerofcode.withgoogle.com/archive/2016/projects/5183714946449408/

Finishing the RW support for it might be a more useful endeavor.

christos