Date: Mon, 29 Jan 2007 11:27:52 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Andrew Pantyukhin <infofarmer@FreeBSD.org> Cc: FreeBSD Ports <ports@FreeBSD.org> Subject: Re: Non-daemon programs requiring kernel modules Message-ID: <20070129112752.obix02qpk44wgo4o@webmail.leidinger.net> In-Reply-To: <cb5206420701281058r4232ad35xfddfc4f29c6ff8ca@mail.gmail.com> References: <cb5206420701280735o6c916639ufbbc941f0927f4c8@mail.gmail.com> <20070128193804.5b2e09ba@Magellan.Leidinger.net> <cb5206420701281058r4232ad35xfddfc4f29c6ff8ca@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Andrew Pantyukhin <infofarmer@FreeBSD.org> (from Sun, 28 Jan =20 2007 21:58:28 +0300): > On 1/28/07, Alexander Leidinger <Alexander@leidinger.net> wrote: >> Quoting "Andrew Pantyukhin" <infofarmer@FreeBSD.org> (Sun, 28 Jan =20 >> 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 =20 want to apply it to the linux stuff? I see the problem, that if you try to do a generic solution, users =20 want it for the linux stuff too. There's not problem with such a =20 request from a high level point of view, but technically I don't see =20 how this can be done in a reasonable way for the linux stuff. For =20 acroread or skype, we could do it very easy (there are already FreeBSD =20 shell scripts as wrappers, so we could check with "kldstat -v | grep =20 linux"), but users would expect something like this in a lot more =20 places then. In some places you just can not do it, because those =20 programs are also used by linux stuff internally or can be used in a =20 chroot. It's like using a program which issues some ioctls which are =20 valid for SCSI devices, but not ata devices (or vice versa). Or if you =20 want to use SYSVSHM and it isn't available in the kernel. The user =20 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 =20 some stuff but not all stuff. If we are able to do it for all stuff, =20 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 =20 parse the output of "kldstat -v" and determine if aio is compiled into =20 the kernel or loaded as a module. If it is loaded as a module, check =20 if it is enabled in loader.conf. If this is not the case, fail to =20 install/build with a suitable message. This is (more or less) how we =20 do it in the linux ports. Bye, Alexander. --=20 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. =09=09-- Ogden Nash http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070129112752.obix02qpk44wgo4o>