[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC: removing hardcoded "modprobe blktap" in xencommons



>>> On 12.07.13 at 18:12, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> Back before 4.3 release you complaint about the hardcoded modprobe for
> blktap / blktap2 in xencommons script. I started to look into it this
> week and tried to do this modprobe automatically in libxl (that's the
> idea we discussed before 4.3 IIRC).
> 
> Unfortunately I didn't manage to find any canonical documents on how a
> user space process can trigger a modprobe. I've looked at kernel
> documentations and couldn't find any. Do you have any reference on how
> to do that?

Not sure what you're asking about. system("modprobe <modname>")
is what I'd start with, or utilizing any process spawning internal
interface libxl already has.

> And, why do you think it is bad to have "modprobe blktap" in xencommons?
> What about not removing it?

I think the discussion why this is a bad idea was long settled: It is
bad practice to load all sorts of stuff regardless of whether it's
actually used - not only from a resource usage pov, but also from
a security one (less kernel code running implies less kernel bugs to
worry about allowing an eventual exploit).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.