[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Operating system independence; Hurd Port.

From: Neal H Walfield
Subject: Re: [PATCH] Operating system independence; Hurd Port.
Date: Sat, 31 Mar 2001 15:05:59 +0200
User-agent: Mutt/1.3.15i

> Anyway, I think the abstractions are bad.  Basically, you separated the
> code by what was convienient to do.

I seperated the code by what was arch specific.  I feel this is in
keeping with other projects namely libc.

> I think we should do something similar to the way disk.c and disk_*.c work.
> The main difference is we don't need to support multiple platforms
> simultaneously, in the one binary.  This is basically an abstract class.
> So, I propose that we have 3 files: device.c, device_linux.c, device_gnu.c
> (BTW, why not device_hurd.c?)

I imagine both are reasonable and hurd might in fact be better as we
target the services provided by the hurd and not the whole system.
If we targeted the whole system, then I would prefer device_linux_gnu.c
or some such and device_gnu.c.

> Second, we have an API between device.c and device_*.c.  This will hopefully
> be pretty much one way, but the general convention is: private functions
> in device.c that we want device_*.c to see we call _ped_device_*(), and
> _arch_device_*() in device_*.c
> ped_device_stat(), ped_device_probe_all() and _do[_refresh]_{open,close} 
> should
> be moved into os-dependent code.
> So, the arch interface is something like:
> _arch_device_{new,stat,[refresh]_{open,close},read,write,check,sync}
> _arch_probe_all
> the private _ped_device() interface would be:
> _ped_device_alloc()
> _ped_device_free()
> _ped_device_register()
> _ped_device_unregister()
> The PedDevice interface in <parted/device.h> would be unchanged.
> Sane?

As you are doing the long term maintaining, I leave this in your hands,
however, I have one primary concern:  what happens when we have another
port?  Which is to say, someone ports to a BSD.  The BSD port could share
50% of the Linux code.  In your model, I see cutting and pasting.  In
the libc model, we continue with the sysdeps abstraction and create a
generic repository.

As for the naming scheme, I do not like it at all.  _arch_* and _ped_*
should be unified.  What happens when a new port forces _ped_foo ()
to change to _arch_foo?  Grep?

Attachment: pgpg5Lum6alMk.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]