|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] [PATCH] large file support for lomount (for 32-bit dom0)
> On 06/11/2009 22:11, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>
> >> Since it is very helpful for recovering from an update to
> >> an in-guest kernel (which is often useful in xen development
> >> but probably also periodically useful to support xen distros), I'd
> >> propose that CONFIG_LOMOUNT get turned on by default in Config.mk.
> >> If we get complaints, it's easy enough to turn it back off later.
> >
> > Another point is that it's almost certainly Linux-specific;
> at least the bit
> > that sets up the loopback mount. We could perhaps just get rid of
> > CONFIG_LOMOUNT and unconditionally build lomount on Linux only.
>
> Ah, now I see lomount was disabled by default in c/s 16742,
> which was by Ian
> Jackson and has a detailed changeset comment. It seems he
> thinks there are
> fine alternatives to lomount these days.
Well perhaps it is 22 months too late to argue the point but
that never stopped me:
Lomount is:
1) Documented in xen books
2) The answer to MANY "how do I..." questions posted
on many web pages (including vendor support sites).
3) Far simpler than the alternative obscure and complex
sequence of arcane magic commands that only a filesystem
expert is able to remember or safely use.
4) Very useful for dev activities where multiple kernels
are being tested within a single VM.
Now clearly I can enable it whenever I install a
clean version of Xen. I can also probably enable it
for every future Oracle VM distro release (though it's
too late for our recent 3.4-based release now).
But isn't this just another case of ultra-alpha-developers
making it as difficult as possible for mortal developers
to contribute to Xen? Surely it should be fine to
enable it for the xen-unstable tree?
Time for a weekend... :-)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|