IMP Quota command driver, was Re: [dev] Bounties

[Etienne Goyer]

On Fri, Jan 30, 2004 at 04:50:08PM -0600, Eric Rostetter wrote:
> > I prefer 1 for reasons I will explain below.
> 
> I prefer a third option.  Locating the proper home directory and use the
> quotas on that device.

Outside of getting the pwnam home dir entry, and then parsing the output
of mount looking for the partition that house this directory, I don't
see how to do that.  And even that would be really flaky as the output
of mount(8) is OS/version dependant.
 
> >  Considering that the current driver is broken for
> > (apparently) many people, we have the choice of either leave it as it
> > is, or fix it with the limitation of only be able to deal with quota on
> > one partition.
> 
> No, the choice is leave it as it is (so it doesn't break for people using
> it for whom it does work) *until* we can fix it properly (so it works for
> everyone).

And, in the meantime, it stay broken for most users.
 
> > My fix, BTW, is completely backward-compatible so it
> > will not affect those for whom the driver currently work.
> 
> Wrong.  It currently works for me, and your patch will not.

No, it would.  Have you read the code ?  I coded it with
backward-compatibility in mind.  You don't even have to change your
config.  If the 'new_quota'(*) param is not set, it behave as it does
currently.

*: the 'new_quota' param is a little backward.  It could be changed for
something like 'output_style', which could default to 'standard' to
mean the current behavior, or be setted to 'rh-compatible' for those
that have use the same as I and AJ do.

> > Personnally, I'll fix it with limitation considering that this
> > limitation will not affect most users and can be documented.  Or we can
> 
> That would not make me happy...  It would break my installation.

No.  See above.

> > wait until someone come up with a general solution, which may never
> > happen.  I don't have the commit bit so I'll leave the decision to
> > whoever is responsible.
> 
> Or, keep working on it.  Keep asking for help on the list, etc.  Eventually
> we'll get there.  I'd do it, but I just plain don't have the time right
> now...

No.  I'm out of here.  I already spent wayyyyyy too much time on this, 
and I can see no end to it if I have to accomodate every convulated
quota setup possible.  

Let me resume the situation :

1. We have a piece of code that is currently broken for some (most ?) 
people.

2. We have a fix that is backward-compatible and will work for the
majority (I suppose) of people for whom it currently don't work.

So my proposition is on the table.  It break nothing (that I know of, 
that is), including Eric's setup.  It's an incremental improvement over 
the current situation.  I am willing to clean up my work enough to have 
it integrated and that's about it.


-- 
Etienne Goyer                    Linux Québec Technologies Inc.
http://www.LinuxQuebec.com       etienne.goyer at linuxquebec.com

Kernel Preemption is a bad idea. Who are the users to think their 
trivial tasks are more important than the kernel's ?