FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-24-2011, 01:48 PM
Richard Shaw
 
Default Need systemd unit file help.

I just took over the akmods package at RPM Fusion and one of the many
BZ requests is to convert it to systemd.

The current suggestion is:
[Unit]
Description=Builds and install new kmods from akmod packages
After=syslog.target
Before=prefdm.service

[Service]
Type=oneshot
ExecStart=-/usr/sbin/akmods --from-init

[Install]
WantedBy=multi-user.target

But this only works for people using the video driver akmod packages.
There are also other packages such as network drivers and possibly
others.

Is there some way to make this more dynamic so that the run
dependencies can be defined by what akmod packages are installed?

I think I remember reading a thread where one unit file can call other
unit files? Is there some way to setup a akmods.d/ type directory
where the individual akmod driver packages can stick unit files?

Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-25-2011, 12:01 PM
Michal Schmidt
 
Default Need systemd unit file help.

On Sat, 24 Sep 2011 08:48:16 -0500 Richard Shaw wrote:
> I just took over the akmods package at RPM Fusion and one of the many
> BZ requests is to convert it to systemd.
>
> The current suggestion is:
> [Unit]
> Description=Builds and install new kmods from akmod packages
> After=syslog.target
> Before=prefdm.service
>
> [Service]
> Type=oneshot
> ExecStart=-/usr/sbin/akmods --from-init
>
> [Install]
> WantedBy=multi-user.target
>
> But this only works for people using the video driver akmod packages.
> There are also other packages such as network drivers and possibly
> others.
>
> Is there some way to make this more dynamic so that the run
> dependencies can be defined by what akmod packages are installed?
>
> I think I remember reading a thread where one unit file can call other
> unit files? Is there some way to setup a akmods.d/ type directory
> where the individual akmod driver packages can stick unit files?

You can have every akmod-* package ship
a /lib/systemd/system/akmod-*.target file to specify the ordering, e.g.
akmod-foo-video-driver.target:

[Unit]
Description=akmod for foo
After=akmods.service
Before=prefdm.service

And ship a symlink
/lib/systemd/system/akmods.service.wants/akmod-*.target


Or, instead of building all the modules from akmods.service, you
can build them using 'akmods --akmod ...' from their own akmod-*.service
where the ordering will be defined as needed.

Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-25-2011, 06:17 PM
Richard Shaw
 
Default Need systemd unit file help.

On Sun, Sep 25, 2011 at 7:01 AM, Michal Schmidt <mschmidt@redhat.com> wrote:
> You can have every akmod-* package ship
> a /lib/systemd/system/akmod-*.target file to specify the ordering, e.g.
> akmod-foo-video-driver.target:
>
> *[Unit]
> *Description=akmod for foo
> *After=akmods.service
> *Before=prefdm.service
>
> And ship a symlink
> /lib/systemd/system/akmods.service.wants/akmod-*.target

So this method will run on the earliest requirement of all installed
akmod packages?


> Or, instead of building all the modules from akmods.service, you
> can build them using 'akmods --akmod ...' from their own akmod-*.service
> where the ordering will be defined as needed.

Here they provide their own .service file and akmods could be run more
than once during boot if the user has more than one akmod package
installed?

I like the first option because it seems more elegant, but also more
complicated. I like the second option because it puts the onus of
getting the .service file right on the maintainer of the driver
package and not me

Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-25-2011, 07:49 PM
Kevin Kofler
 
Default Need systemd unit file help.

Richard Shaw wrote:

> On Sun, Sep 25, 2011 at 7:01 AM, Michal Schmidt <mschmidt@redhat.com>
> wrote:
>
>> Or, instead of building all the modules from akmods.service, you
>> can build them using 'akmods --akmod ...' from their own akmod-*.service
>> where the ordering will be defined as needed.
>
> Here they provide their own .service file and akmods could be run more
> than once during boot if the user has more than one akmod package
> installed?

I think the idea is to run it only for each specific akmod, not for all at
once.

> I like the first option because it seems more elegant, but also more
> complicated. I like the second option because it puts the onus of
> getting the .service file right on the maintainer of the driver
> package and not me

I think the second option is more elegant, it fits more into the spirit of
parallelized boot. I guess it even allows building independent akmods in
parallel.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-26-2011, 04:32 PM
Lennart Poettering
 
Default Need systemd unit file help.

On Sat, 24.09.11 08:48, Richard Shaw (hobbes1069@gmail.com) wrote:

> I just took over the akmods package at RPM Fusion and one of the many
> BZ requests is to convert it to systemd.
>
> The current suggestion is:
> [Unit]
> Description=Builds and install new kmods from akmod packages
> After=syslog.target

(Starting with F16 After=syslog.target is not necessary anymore and
should be dropped from unit file. But that's orthogonal to your mail
otherwise.)

> Before=prefdm.service
>
> [Service]
> Type=oneshot
> ExecStart=-/usr/sbin/akmods --from-init
>
> [Install]
> WantedBy=multi-user.target
>
> But this only works for people using the video driver akmod packages.
> There are also other packages such as network drivers and possibly
> others.
>
> Is there some way to make this more dynamic so that the run
> dependencies can be defined by what akmod packages are installed?

Well, you can move your service into the early boot part if
necessary. However, there's a fundamental problem here: iiuc you compile
driver modules at boot and want them recognized by the system during the
same boot run. That's hardly possible though. To compile your modules
you probably need the full set of file systems around (i.e. /var and
/tmp), but that's only available after udev was started and driver
loading triggered. So the earliest time you can build the drivers is
already too late to load them properly.

My question to you: why are these modules built at boot time at all? Why
not at install time? Seems like the more appropriate time to me, given
that the set of kernel packages does not change during boot, but only at
install time.

> I think I remember reading a thread where one unit file can call other
> unit files? Is there some way to setup a akmods.d/ type directory
> where the individual akmod driver packages can stick unit files?

You can do something similar the way Michal suggested.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-26-2011, 05:32 PM
Reindl Harald
 
Default Need systemd unit file help.

Am 26.09.2011 18:32, schrieb Lennart Poettering:

> My question to you: why are these modules built at boot time at all? Why
> not at install time? Seems like the more appropriate time to me, given
> that the set of kernel packages does not change during boot, but only at
> install time.

because akmods is used to build kernel-modules after the kernel
was updated and the komd-package not - this was before vmxnet3
as example hardly needed for vmware because without network
yum makes no fun

another example are the nvidia-drivers - for normal users
it is not acceptable have no GUI after update / reboot

normally the kmod-packages are updated the same time
as the kernel in stable repos, but you can not guarantee
this for external repos everytime, especially that the
mirror you catched is recent enough

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-26-2011, 05:34 PM
Doug Ledford
 
Default Need systemd unit file help.

----- Original Message -----
> Well, you can move your service into the early boot part if
> necessary. However, there's a fundamental problem here: iiuc you
> compile
> driver modules at boot and want them recognized by the system during
> the
> same boot run. That's hardly possible though. To compile your modules
> you probably need the full set of file systems around (i.e. /var and
> /tmp), but that's only available after udev was started and driver
> loading triggered. So the earliest time you can build the drivers is
> already too late to load them properly.

You can always trigger the device you are building for again once the build is complete.

> My question to you: why are these modules built at boot time at all?
> Why
> not at install time? Seems like the more appropriate time to me,
> given
> that the set of kernel packages does not change during boot, but only
> at
> install time.

Because a kernel install can happen after the package that rebuilds the module is installed and the kernel rpm doesn't itself build these modules. Now, you might be able to use a %trigger in rpm, but in general, several people in the past have resorted to boot time builds so that if you boot up on a new kernel and the custom driver was already installed, then the custom drivers get built for the new kernel. In some cases (although it can probably be argued this is a bad driver make process), the driver might require the running kernel be what it is building for and then you would *have* to wait until the first time that particular kernel is booted to build the module.

So, long story short, there are difficulties, not the least of which is the poorly understood usage of the %trigger capabilities in rpm.

--
Doug Ledford <dledford@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-26-2011, 07:54 PM
Kevin Kofler
 
Default Need systemd unit file help.

Reindl Harald wrote:
> because akmods is used to build kernel-modules after the kernel
> was updated and the komd-package not - this was before vmxnet3
> as example hardly needed for vmware because without network
> yum makes no fun
>
> another example are the nvidia-drivers - for normal users
> it is not acceptable have no GUI after update / reboot
>
> normally the kmod-packages are updated the same time
> as the kernel in stable repos, but you can not guarantee
> this for external repos everytime, especially that the
> mirror you catched is recent enough

But akmods are a very hackish solution to that problem. Building modules on
the end user system sucks on a binary distribution. It drags in the whole
GCC toolchain, kernel-devel and the source code for the modules and the
whole system is a huge kludge, as evidenced also by this thread.

The right solution is for the user to just uncheck the kernel from the list
of packages to update in the PackageKit GUI of choice (be it gnome-
packagekit, KPackageKit or Apper) if the kmod doesn't show up along with it.
It's not rocket science.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-26-2011, 08:00 PM
Richard Shaw
 
Default Need systemd unit file help.

On Mon, Sep 26, 2011 at 2:54 PM, Kevin Kofler <kevin.kofler@chello.at> wrote:
> But akmods are a very hackish solution to that problem. Building modules on
> the end user system sucks on a binary distribution. It drags in the whole
> GCC toolchain, kernel-devel and the source code for the modules and the
> whole system is a huge kludge, as evidenced also by this thread.

Yes, but it works


> The right solution is for the user to just uncheck the kernel from the list
> of packages to update in the PackageKit GUI of choice (be it gnome-
> packagekit, KPackageKit or Apper) if the kmod doesn't show up along with it.
> It's not rocket science.

No, it's not rocket science, but it does require manual intervention
on the part of the user who may or may not understand the relationship
between the kmod driver and the kernel. Shouldn't updating (by kmod,
or akmod) be more or less transparent to the end user?

Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-26-2011, 08:06 PM
Reindl Harald
 
Default Need systemd unit file help.

Am 26.09.2011 21:54, schrieb Kevin Kofler:
> Reindl Harald wrote:
>> normally the kmod-packages are updated the same time
>> as the kernel in stable repos, but you can not guarantee
>> this for external repos everytime, especially that the
>> mirror you catched is recent enough
>
> But akmods are a very hackish solution to that problem. Building modules on
> the end user system sucks on a binary distribution. It drags in the whole
> GCC toolchain, kernel-devel and the source code for the modules and the
> whole system is a huge kludge, as evidenced also by this thread.
>
> The right solution is for the user to just uncheck the kernel from the list
> of packages to update in the PackageKit GUI of choice (be it gnome-
> packagekit, KPackageKit or Apper) if the kmod doesn't show up along with it.
> It's not rocket science.

well - nobody is forcing you to use akmod
there are kmod-open-vm-tools AND akmod-open-vm-tools

as example i have the akmod-packages on the buildmachine
if there is an important security-kernel-update and kmod
packages not available this machine builds the binaries

the other machines get the kernel-update via deployment-scripts
AND the pre-compiled kernel-modules from akmod





--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 03:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org