Re: [Evms] Questions about portability

[Andrew Clausen]

Christoph Hellwig wrote:
> > > We only have to take care of having the full resize done before any
> > > other OS tries to access it.
> >
> > Parted does resizing off-line (it's userspace).
> 
> Right, I forgot that while discussing. On the other hand I understand
> your inital argument no more.

The idea is: the CONSTRAINTS are simple, but the calculation of
constraints isn't.

> > Although, we intend
> > to interface the online resizers too...
> 
> That would of course be nice - but before that Andreas must get his
> patches in...

He hasn't already?  (I thought he had... I don't really follow the
kernel much, though...)

> > Your (only?) arguments in favour of having the do-it-all library calling
> > other programs (as opposed to the programs calling the do-it-all
> > library)
> > is language compatibility issues and "forced" code sharing?
> 
> Those are two, but here are some additional arguments:
>   - this way you can easily write different frontends without a need
>     to use the library (this again includes the language argument).
>   - with separate programs I can esily use (and install) e.g.
>     resizefs.ext2 separate without the bloat of a full library.

The full library isn't bloated, because you only need the modules
you want.  There may be slightly more bloat for the "core" library,
but there's likely to be more code-reuse, so if there are many
modules (that you want simultaneously), then there is less bloat
in total.

>   - it's more UNIXish (and I _really_ like the UNIX way of doing things)

I'm not convinced here.  Say, compare this to something like the
standard ftp client.  Should it have separate binaries for "ls",
"get", "mget", etc?  Why doesn't it?  (because ftp runs on a
connection?)
Could similar arguments be made about this stuff?  (the programs
aren't really independent - it doesn't make sense (in MOST cases) to
run these programs on their own?)
 
> > > But when the different resizers are actually the same binary it
> > > should be trivial.
> >
> > You mean, when the resizers + the partition table code...
> >
> > Anyway, it isn't trivial, because the code needs to maintainable and
> > modular,
> > and needs to have a consistent interface (to be useful).
> 
> We were only talking about the fat family of filesystems, weren't we?

Yes, but file systems and partition table code are in completely
separate modules.  Actually, the way libparted deals with this is
quite ugly, IMHO.  File systems need to know about all partition
tables (rather than the other way around, which is The Right Thing)
We need to do it like this, just because of the fat16/32 issue.

> > > > Why?  No-one should care about a change from fat16 -> fat32.  If you
> > > > are doing a whole series of operations on a partition, should you
> > > > have to check the file system type every second, to make sure you're
> > > > calling the right function?  (compulsive obsessive disorder! yay!)
> > >
> > > Win < 95b and NT < 2000 cares.
> >
> > Yeah, you should warn the user about it... but Linux tools shouldn't
> > care.  BTW, this is another argument for a library.  How does an
> > all-in-one front-end (eg: a GUI installer, an automatic partitioner,
> > or whatever) communicate error messages?  What if the user has
> > multiple ways of resolving an error (eg: retry, ok, cancel, etc.)
> 
> Hmm, I haven't thought about that - just because it is very unusual
> for unix tools to ask such questions, they just fail if an error occours.

Which is often very frustrating.  It's often very difficult to discover
what the error was, and often, you can do intelligent recovery...

Eg: Unix handles running out of HD space VERY badly.  X usually crashes,
and goes into a cycle of crash, attempt restart, crash...

Users tend to have to LOOK for the problem (i.e. the cause), rather than
have it presented to them.  (This is true for basically all software,
not just Unix.  At least with Unix, it's usually possible to find the
problem...!)

Enough ranting.  Just, I don't like Unix error handling.

> > One solution would be to read/write to stdin/stdout, etc., but then you
> > need more conventions on the protocol (i.e. user interface for the
> > low level tool).  This get's tricky, with i18n issues.
> 
> Right - but if you use tools from other programs it makes sense to set the
> locale to C for the invoked program anyway if you want to at least under-
> stand it's messages (just imagine it would be Japanese or so ...)

But, how do you present the error message to the user?  (With the
appropriate options, etc.)  You want to do this in the native language,
right?

Andrew Clausen