lkml.org 
[lkml]   [1999]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectFW: How do I do it? (was Re: Accountability)
Date
Here's some info.

-----Original Message-----
From: Andreas Dilger [mailto:adilger@enel.ucalgary.ca]
Sent: Thursday, September 16, 1999 1:27 AM
To: linux-kernel@vger.rutgers.edu
Subject: How do I do it? (was Re: Accountability)


On a more positive side of the "Accountability" thread, let's see what
CAN be done to get things into the kernel... I'm a relative newcomer
here (too much traffic for my liking before I had a kernel patch to care
about), so bear with me.

I have written a kernel patch which will allow resizing of an ext2
filesystem while it is mounted (online-ext2 is available at my web page:
http://www-mddsp.enel.ucalgary.ca/People/adilger/online-ext2/

1) My kernel patch does the minimal work it needs to, and the rest is done
as user-space utilities, which I think is the desirable way to go, as
we don't wan't the kernel to be able to do a mke2fs necessarily. So far
so good?
2) I re-used what existing kernel code I could, made it more generic in
some cases, to handle what I needed to do. Presumably this is the
correct way to go?
3) I have read about formatting of code for the kernel, and have tried to
follow them. Would patches be rejected for having too many comments?
4) There are some known "issues" in the patch (e.g. it turns off quota
checking while not having the lock on the filesystem for a "brief
instant"
because it is calling a function which grabs the superblock lock itself).
Is this "permitted", considering the combination of quotas, frequency of
filesystem resize, and a "one-line" chance of being interrupted before
getting the superblock lock again is considered small enough to justify
not making more changes to the kernel?
5) Since the userspace tools aren't 100% ready for public consumption, is
there any chance of getting the patch into 2.3.x? I wanted to have the
user code ready before trying to get the patch into the mainstream kernel
(to avoid more patches to the kernel), but in my testing the kernel code
is ready for use. The resize functions added by the patch sits totally
off
the main code path, so do not have any real performance impact at all if
they are added.
6) With a new feature like this, would it be required to have an option to
turn it on/off via menuconfig? The patch will add a useful capability
to the kernel even if people don't have the user-space tools required for
full functionality (ie an unmodified "mount" command can do wonders for
you if required). However, to really get use out of this patch, you need
to be able to resize your underlying device size via md or hardware RAID,
or most likely LVM.

Trying to be a good l-k participant...

Cheers, Andreas
--
Andreas Dilger University of Calgary \ "If a man ate a pound of pasta and
Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.141 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site