Subject: Re: fparseln() in libutil?
To: None <tech-userlevel@netbsd.org>
From: Leo Weppelman <leo@wau.mis.ah.nl>
List: tech-userlevel
Date: 08/03/1999 16:18:58
[ I posted this as an article on muc.lists.tech.userlevel, but it does not
seem to make it to tech-userlevel. Therefore a repost. If you get it twice,
my apologies ]

In article <199908021756.KAA08267@lestat.nas.nasa.gov>,
Jason Thorpe <thorpej@nas.nasa.gov> wrote:
>On 01 Aug 1999 22:49:00 -0700 
> cgd@netbsd.org (Chris G. Demetriou) wrote:
>
> > why's fparseln() in libutil rather than in libc?
> > 
> > it, getmaxpartitions, and getrawpartition seem like they belong more
> > in libc (along with stdio and getdiskbyname and friends) than in
> > libutil...
>
>fparseln() yes.. I agree.  I don't really care that much about the
>others, tho :-)

Well, I do ;-) I want to eliminate the use of MAXPARTITIONS from
disklabel.c:getdiskbyname() since it makes libc unsharable between
the m68k-ports... I asked Chris' opinion about it, so that's why it is
brought out here.

And while I am typing now anyways:

To accomplish the elimination of MAXPARTITIONS, there are 3 options:
    1) Call getmaxpartitions() from libutil
    2) Call sysctl directly (i.e. mimic getmaxpartitions())
    3) Move getmaxpartitions() to libc

Chris seems to favor 3, and the way things are evolving, I think that
might indeed be the best.

Apart from the change to disklabel.c, include/sys/disklabel.h needs changing
too. The d_partitions-array should have size MAXMAXPARTITIONS (Hi Chris ;-)
The assumption is that  DISKUNIT(), DISKPART() and MAKEDISKDEV() are only
used inside the kernel, so they don't need modification. It was on my
todo list for today to check that out, but I came accross this discussion 
before that ;-)

Leo.