On Fri, Dec 13, 2013 at 12:48:31PM +0200, Nikos Skalkotos wrote:
> > Now the library is good enough for dialogs driven interfaces (like
> > fdisk), but it's necessary to improve it for programs like cfdisk and
> > sfdisk. Now I'm working on new cfdisk.
>
> Actually I wanted to ask you about this. I've seen the fdisk_ask struct
> and how the client can registers an ask_callback function, but it's not
> clear to me how you are planning to allow programs to use the
> library in an unattended way. Are you going to provide new methods
See libfdisk branch on github. There is a new 'struct fdisk_partition'
and some functions to modify this struct (well, it's not complete
yet). The idea is to use the struct as template for operations like
add partition. So the primary source for information will be the
template otherwise label drivers will ask by fdisk_ask API.
> If you rewrite sfdisk to use the library, I'll get all the answers I
> need. :-)
Probably something like:
struct fdisk_partition *pa = fdisk_new_partition();
fdisk_partition_enable_default_start(pa);
fdisk_partition_set_size(pa, 1024 * 1024 * 1024);
fdisk_add_partition(cxt, pa);
to create 1GiB partition at the begin of the free space.
I can also imagine something like --interactive for sfdisk, so it will
possible to use incomplete input and then it will ask for the missing
things.
I guess it will be usable in python binding, because "*pa" could be an
object, so you can do things like:
cxt = FdiskContext("/dev/sda")
pa = FdiskPartition()
pa[SIZE] = 1024 * 1024 * 1024
pa[START] = FDISK_DEFAULT
cxt.add(pa);
or so....
> or are you going to document the data each method will ask
> for to allow the user to provide the answers in advance?
I thought about it, for example add names for the ask API questions to
make it possible for the ask_callback function to detect what exactly is
wanted. But it seems to complex and callbacks driven libraries suck :-)
(except UI events libs, etc.)
It would be probably better to keep the current ask API restricted to
things like err/warn messages, tables outputs and simple dialogs for
programs like fdisk.
Anyway, I believe that dialog driven fdisk is the best possible way
for advanced users because you can *talk* directly with label specific
code about label specific stuff. It's better than use extra
abstraction layers to describe labels and devices. Unfortunately, for
programs like sfdisk we need something else (but I still believe that
we can make things in more lightweight way compare to libparted ;-)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
