Re: [Evms] Questions about portability

[Christoph Hellwig]

On Mon, Nov 13, 2000 at 10:17:31AM -0200, Andrew Clausen wrote:
> > If we implement the partition table support as part of a LVMS,
> > it should be easy to do LVM-like resizing even on partition tables.
> 
> What is "LVM-like resizing"?  Do you mean resize.ext2, etc?  (If this
> is the case, then I disagree, obviously, hehe)

No.  

  a) I actually meant lv (or partition) moving ;)
  b) that means it is done block for block using block remapping.

> > 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.

> Although, we intend
> to interface the online resizers too...

That would of course be nice - but before that Andreas must get his
patches in...

> > Also it is not what I call a really clean design I like this more then
> > a doit all library.
> 
> s/Also/Although/  ?

Yes, sorry.

> 
> Well, I certainly think it's good to have both a program AND a library
> interface.  (I want to have the do-it-all library, even if it delegates
> things out by exec()ing other programs)

That's great - I don't have an objection against an do-it-all library
as long as I can use the nice functionality in the exec()ed programs
without it!

> 
> 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.
  - it's more UNIXish (and I _really_ like the UNIX way of doing things)

> > 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?

> 
> > > 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.

> 
> 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 ...)

> 
> The programs-that-are-a-front-end-to-a-big-library approach doesn't
> have this problem.

Right.

        Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.