LCDproc development and user support list

Text archives Help


[Lcdproc] lcdproc (client) completely ported to NetBSD.


Chronological Thread 
  • From: reenoo AT gmx.de (Rene Wagner)
  • Subject: [Lcdproc] lcdproc (client) completely ported to NetBSD.
  • Date: Sat Aug 16 17:55:02 2003

On Fri, 2003-08-15 at 01:47, Guillaume Filion wrote:
> > No, a header is a contract about the interface. And the interface
> > must be the same for all platforms, it's just the implementation
> > that is different. So we will have something like batt.h and batt.c
> > that contains machine independent (MI) code (protocol handling etc.)
> > and one machine dependent (MD) file per supported OS which includes
> > all functions to get the statistics/values (lets call it
> > foo_<uname -s>.c). In addition there is a foo.h that defines the
> > MD functions (gets included by batt.c and MI friends).

Actually, that's pretty close to the way drivers are implemented ATM.
So, yes, splitting system/platform dependent code should be a good
idea.

> > The
> > Makefile does the magic of only compiling the relevant
> > foo_<uname -s>.c file, possibly doing some magic by calling the
> > systems uname(1), assigning it to a variable and using that for
> > further processing.

We would have to use the autotools for that though.

> > If we have multiple OS's with the same interface, I'd simply copy
> > the file and use that. The interface of one OS might change in the
> > future, while the other stays the same or develops into another
> > direction.

At the beginning this seemed a little like reinventing the wheel to
me...
But the only library I'm aware of which provides the required
functionality is libgtop (Please correct me if you know of other libs).
And, unfortunately, I haven't found anything specific about libgtop's
current status and I'm unsure if it is a good idea to use it.

> > It's easy for the port maintainers to keep in sync.
> > Hmm, maybe we should assign names to the ports to the different
> > OS's, so we have a central point to send requests, suggestions
> > and/or complains.

IMO the list should remain the address for such things. People tend
to disappear (or have a busy schedule like me ATM) and the risk of
ideas/patches/... ending up in /dev/null seems too high to me.

> > As I was complaining about the current status for years (in the
> > beginning louder, resigning later), I'd volunteer to do the changes.
> > But keep in mind, that I have access to NetBSD boxes only. I need
> > a calm tester with some spare time for every other supported OS
> > or an account on such machine.
> >
> > Thank you. :-)
>
> My pleasure! I'm quite happy that you'll be working on the code; I
> spent numerous hours trying to make your old patch work with the CVS
> version. As for the testing, sourceforge used to have a FreeBSD box in
> the compile farm, but they removed it to replace it with yet another
> Linux.

:(

> A compile farm with only Linux is not very usefull. 8( I don't
> have a FreeBSD or OpenBSD box here but I guess/hope someone on this
> list will.

I have a FreeBSD 4.6 system here. Feel free to send me code for
testing.

>
> So is there a charitable soul that could give Thomas an account on a
> FreeBSD and/or OpenBSD box?

Sorry, most of the time that particular system is powered off and
also unreachable from the outside anyway.

Regards,

Rene





Archive powered by MHonArc 2.6.18.

Top of page