Non-daemon programs requiring kernel modules

Alexander Leidinger Alexander at
Mon Jan 29 10:28:05 UTC 2007

Quoting Andrew Pantyukhin <infofarmer at> (from Sun, 28 Jan  
2007 21:58:28 +0300):

> On 1/28/07, Alexander Leidinger <Alexander at> wrote:
>> Quoting "Andrew Pantyukhin" <infofarmer at> (Sun, 28 Jan   
>> 2007 18:35:30 +0300):
>>> I'm porting a simple util requiring aio(4). My plan is
>>> to install a wrapper script which includes rc.subr(8)
>>> and uses its required_modules mechanism.
>>> If anyone has a better idea, please tell me.
>> Just tell at port/package install time the requirement. Every linux
>> program needs the linux module or the corresponding kernel option. If
>> the code is not available at runtime, the user will get an error. Unix
>> is not for dumb people, so I don't think we need this low-level
>> hand-holding.
> That's one opinion. But Unix is also not about dumb
> developers. As a ports developer, my job is to make
> it easier for users to run third-party software and
> that's just what I'm trying to do to the extent of
> my skills and motivation...

I agree, but if you are interested in a general solution, how do you  
want to apply it to the linux stuff?

I see the problem, that if you try to do a generic solution, users  
want it for the linux stuff too. There's not problem with such a  
request from a high level point of view, but technically I don't see  
how this can be done in a reasonable way for the linux stuff. For  
acroread or skype, we could do it very easy (there are already FreeBSD  
shell scripts as wrappers, so we could check with "kldstat -v | grep  
linux"), but users would expect something like this in a lot more  
places then. In some places you just can not do it, because those  
programs are also used by linux stuff internally or can be used in a  
chroot. It's like using a program which issues some ioctls which are  
valid for SCSI devices, but not ata devices (or vice versa). Or if you  
want to use SYSVSHM and it isn't available in the kernel. The user  
will get an error message because he did the wrong thing.

I think it is more POLA to keep it this way, instead of doing it for  
some stuff but not all stuff. If we are able to do it for all stuff,  
great, go ahead, but in this case I don't think it is a good idea.

You can bail out in the port/package if aio is not available. You can  
parse the output of "kldstat -v" and determine if aio is compiled into  
the kernel or loaded as a module. If it is loaded as a module, check  
if it is enabled in loader.conf. If this is not the case, fail to  
install/build with a suitable message. This is (more or less) how we  
do it in the linux ports.


Some primal termite knocked on wood.
And tasted it, and found it good.
And that is why your Cousin May
Fell through the parlor floor today.
		-- Ogden Nash    Alexander @ PGP ID = B0063FE7       netchild @  : PGP ID = 72077137

More information about the freebsd-ports mailing list