Non-daemon programs requiring kernel modules
Alexander at Leidinger.net
Mon Jan 29 10:28:05 UTC 2007
Quoting Andrew Pantyukhin <infofarmer at FreeBSD.org> (from Sun, 28 Jan
2007 21:58:28 +0300):
> On 1/28/07, Alexander Leidinger <Alexander at leidinger.net> wrote:
>> Quoting "Andrew Pantyukhin" <infofarmer at FreeBSD.org> (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
> 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
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
More information about the freebsd-ports