Re: [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 26/10/17 16:59, Olaf Hering wrote:
> On Thu, Oct 26, Andrew Cooper wrote:
>
>> Can't all information be obtained from /sys/hypervisor?  If not, how
>> hard would it be to make happen?
> Likely not that hard. Not sure why that was not added in the first place.

I've never really understood why xenfs exists in the first place
(although I expect the answer is "Because that is how someone did it in
the past"), and I'm not aware of any other project which needs its own
custom filesystem driver for device nodes.

These days, /dev/xen/ is the preferred location for devices anyway.

Either way, I don't mean to bikeshed the issue, but we should at least
consider whether cleaning this up fully is the easiest course of action.

>
>> What happens to all the software which currently has a dependency on
>> proc-xen.mount ?
> All software gets converted by this change.

Is it possible to express a dependency on proc-xen.mount ||
proc-xen.service?

If not, then out-of-tree packages are going to have compatibility
problems with this change.

>
>> Independently, how does this interact with having a xenfs entries in
>> /etc/fstab, which might plausibly still exist for compatibility with
>> other init systems?
> mount(1) will continue to consider them.

Right, but ISTR that Systemd deals with /etc/fstab by auto-generating
*.mount targets, and from what is said here, it is the proc-xen.mount
target which is now broken by the change in systemd behaviour.

~Andrew`

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