[systemd-devel] Loading Kernel Modules
Pawel Pastuszak
pawelpastuszak at gmail.com
Mon Mar 19 08:23:41 PDT 2012
I guess i would uses so custom logic to do this..
Thanks Kay for the help.
Pawel
On Mon, Mar 19, 2012 at 11:12 AM, Kay Sievers <kay at vrfy.org> wrote:
> On Mon, Mar 19, 2012 at 16:02, Pawel Pastuszak <pawelpastuszak at gmail.com>
> wrote:
> > I am not sure if i made my self clear, what i am doing is and custom
> distro
> > for an custom embedded device, which i want to have the ability to
> upgrade
> > the system in runtime, which i need to ability to to stop my custom
> driver
> > modules for the upgrade. So this is why i was asking what is the best
> way of
> > starting and stop modules.
> >
> > Unless what your saying is replace the file and just reboot, instead of
> stop
> > the service and replace then start it again.
>
> Oh, there is no general advice in the systemd context, I guess. It's
> also not systemd specific, and mostly handled inside the kernel. As
> mentioned, we generally do not support at all any kernel-module
> unloading with systemd-native infrastructure, but that should be no
> reason for custom logic inside a service to do that.
>
> Usually you need to stop the service/application using the device, and
> then you can unload the driver module. Most modules can only be
> unloaded when they are not in use. The most common exception is
> network driver modules, which for historic reasons do not pin the
> modules in use. This can either be managed by completely stopping and
> restarting the service, or by sending specific commands to a service
> to release the open()ed devices.
>
> Alternatively, if the service/app can handle hot-device removal, you
> can just unbind the driver from the device in
> /sys/bus/*/drivers/*/{bind,unbind}, and after that unload the module.
> But the service/app needs to be able to cope with devices
> disappearing; many services/apps don't.
>
> Kay
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20120319/1e5cdf57/attachment.htm>
More information about the systemd-devel
mailing list