On Mon, Aug 19, 2002 at 05:42:30PM -0700, Jim Lynch wrote: > On Mon, 29 Jul 2002 18:46:41 -0400 > Matt Zimmerman <[EMAIL PROTECTED]> wrote: > > I am in complete agreement that we would not want to include EVMS, XFS > > or similar in our default kernel unless (or until) they are part of the > > official kernel. > > Please find the reason for EVMS not being incorporated. Also, is LVM not > going to be part of the kernel in the future? I'm not totally sure about > this part, but I thought I had read that Linus wants LVM out; note that > there have been fairly nasty core-level bugs in LVM in the recent past > (the last one I knew of involved main stack overflow causing big > filesystem problems: I recall patching to kill that particular bug on my > personal machine).
Pay special attention to the word 'default' in my sentence above; it is the core of my opinion on this subject. I believe that the default kernel should be sufficiently generic to enable a wide variety of users to install the system, but not so overfeatured as to be difficult to support, or to introduce too many unknowns into the installation process. There is no reason why these systems should not be options if someone is willing to do the work, but I would caution against their inclusion in the default kernel. > >From what I know about LVM and EVMS, the latter's development is being > carried out by people who understand the kernel; the former, not so much: > some of the LVM developers had a falling out with others; the group who > understood kernel issues were harping on technical issues. They got > kicked off the mailing list for doing so. Hence, they are left with people > who don't understand the kernel quite as much. I don't keep up with LVM, or with kernel politics, and I am not qualified to judge anyone's kernel prowess, but as far as I know, LVM is no longer being actively developed, and current development is focused on LVM2. EVMS is, of course, a separate project. > I propose that we measure the stability of each, and make a decision based > on stability, rather than whether or not a certain module passed political > muster to be included in the kernel. I would add to this that we should be very conservative in our decisions. > I further propose that we take looks at these technologies more often, > looking at the development status and trying things out. This is what kernel-patch packages are for. There don't seem to be any for LVM2 at the moment, but I would like to see one. There is, of course, one for EVMS. > > However, I am willing to do some work to support EVMS in d-i, and to > > provide EVMS-enabled installation media for those who are interested in > > trying it. > > That's definitely more like it... there are many who would want to try > such things. > > It would also be good to work toward standardizing naming of volumes (err, > allowing such naming of volumes to happen in the installer), and allowing > the creation of EVMS, LVM, LVM2 (worth a look!) volumes. Current installer > does not allow these things; I think work in these areas should begin as > quickly as possible. Should the kernel VFS be extended to allow things > along these lines? I had planned to try to build some boot-floppies which could be used with woody to install directly onto EVMS volumes. However, I think the time (if I find that I have it) might be better spent getting something more permanent into debian-installer. Given that I know almost nothing about d-i, this would probably be a significant investment of resources to get up to speed and implement something. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
