headers
Marcus Brinkmann | 6 Sep 2002 01:04
Picon
Favicon

iterator macros and requiring gcc >= 3.0 and -std=c9x

Hi,

I would like some iterator macros for the driver plugin code in the console
client.  I have written this so far:

#define driver_iterate(drv)                                             \
  for (mutex_lock (&driver_list_lock), drv = &driver_list[0];           \
       drv <= &driver_list[driver_list_len - 1];                        \
       drv++, (drv == &driver_list[driver_list_len - 1]                 \
               ? mutex_unlock (&driver_list_lock) : 0)

Which can be used like this:

   driver_t driver;
   driver_iterate (driver)
     {
       printf ("%s\n", driver->ops->name);
     }

Neal pointed out that C99 allows to define variables in statements, so the
following would work:

#define driver_iterate                                                    \
  for (mutex_lock (&driver_list_lock), driver_t driver = &driver_list[0]; \
       driver <= &driver_list[driver_list_len - 1];                       \
       driver++, (driver == &driver_list[driver_list_len - 1]             \
                  ? mutex_unlock (&driver_list_lock) : 0)

Which can be used like this:
(Continue reading)

Permalink | Reply | 6 comments |
headers
Roland McGrath | 6 Sep 2002 01:12
Picon

Re: iterator macros and requiring gcc >= 3.0 and -std=c9x

I made it pass -std=gnu99.  I meant to do that a while ago.  I am fine with
using any C99 or GNU extensions you feel like.  That's why we're GNU.  It
is fine now to be compatible only with GCC 3.2 and later (and we can add a
configure check to enforce it if there is any need).
Permalink | Reply | 1 comment |
headers
Neal H. Walfield | 6 Sep 2002 01:19
Favicon

Re: iterator macros and requiring gcc >= 3.0 and -std=c9x

> I would like some iterator macros for the driver plugin code in the console
> client.  I have written this so far:
> 
> #define driver_iterate(drv)                                             \
>   for (mutex_lock (&driver_list_lock), drv = &driver_list[0];           \
>        drv <= &driver_list[driver_list_len - 1];                        \
>        drv++, (drv == &driver_list[driver_list_len - 1]                 \
>                ? mutex_unlock (&driver_list_lock) : 0)

Despite the fact that there will only ever by a single driver_list, I
think it is clearer to write

#define driver_iterate(driver_list, driver) \
   ...

As a small note, you need to protect DRV during expansion by
surrounding it with parentheses.

> eliminating the need for a user-defined variable.  It's no big deal, but if
> you prefer the second version, we need to use -std=c9x in our CFLAGS.  What
> do you think?

The gcc 3.x manual recommends c99 over c9x.
Permalink | Reply | 1 comment |
headers
Jeff Bailey | 6 Sep 2002 01:19

Re: iterator macros and requiring gcc >= 3.0 and -std=c9x

On Thu, Sep 05, 2002 at 07:12:43PM -0400, Roland McGrath wrote:

> It is fine now to be compatible only with GCC 3.2 and later (and we
> can add a configure check to enforce it if there is any need).

I don't think there's a need.  anyone using Debian can't download
older than 3.2 anymore.  Anyone compiling from scratch won't be able
to build glibc without 3.2 shortly.

Tks,
Jeff Bailey

--

-- 
At last you cry out in anguish: "Why me?"
God answers: "Why not?"
 - Sheldon Kopp
Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 6 Sep 2002 01:27
Picon
Favicon

Re: iterator macros and requiring gcc >= 3.0 and -std=c9x

On Thu, Sep 05, 2002 at 07:19:52PM -0400, Neal H. Walfield wrote:
> Despite the fact that there will only ever by a single driver_list, I
> think it is clearer to write
> 
> #define driver_iterate(driver_list, driver) \
>    ...

I see your point, but I think I will leave it in the new form without any
arguments.  The driver_list* variables are only exported for this macro, and
otherwise internal to the driver module.  As you said, there will always ever
only be one driver list, and thus I want to keep it as simple as possible for now.

The driver_load etc functions don't get a driver_list argument either.

> As a small note, you need to protect DRV during expansion by
> surrounding it with parentheses.

Not any longer :)  Since Roland changed it, it's gone.

> The gcc 3.x manual recommends c99 over c9x.

With Roland choosing gnu99, this is moot as well.

Thanks,
Marcus 

--

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus <at> gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann <at> ruhr-uni-bochum.de
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miles Bader | 6 Sep 2002 11:23
Picon
Picon

Re: iterator macros and requiring gcc >= 3.0 and -std=c9x

Marcus Brinkmann <Marcus.Brinkmann <at> ruhr-uni-bochum.de> writes:
>    driver_iterate
>      {
>        printf ("%s\n", driver->ops->name);
>      }
> 
> eliminating the need for a user-defined variable.  It's no big deal, but if
> you prefer the second version, we need to use -std=c9x in our CFLAGS.  What
> do you think?

Even if C99 lets you declare the variable in the for loop (eliminating
the need for a user-declaration), it still seems cleaner to pass the
name of the variable to be declared as a macro argument.

That way the name `driver' isn't magic.  It also lets the user nest your
construct (however silly that may be...).

-Miles
--

-- 
.Numeric stability is probably not all that important when you're guessing.
Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 6 Sep 2002 22:16
Picon
Favicon

Re: iterator macros and requiring gcc >= 3.0 and -std=c9x

On Fri, Sep 06, 2002 at 06:23:37PM +0900, Miles Bader wrote:
> Even if C99 lets you declare the variable in the for loop (eliminating
> the need for a user-declaration), it still seems cleaner to pass the
> name of the variable to be declared as a macro argument.
> 
> That way the name `driver' isn't magic.  It also lets the user nest your
> construct (however silly that may be...).

I agree in general.  In this case though, the macro is only used internally
(eg, the user is the same program as the one that defines the macro), and it
is just more convenient to have it completely automagic.

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus <at> gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann <at> ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 6 Sep 2002 22:06
Picon
Favicon

console plugins

Hi,

I wrote plugin support, and tested it today.  The current plan is as this:

/lib/hurd/VERSION/console/DRIVER.so

where VERSION is 0.3 right now and DRIVER is "vga", "pckbd" etc.

For this, it seems I need to hardcode the library search path in the
console-console executable with -Wl,-rpath=$(libdir)/hurd/$(hurd-version)/console.
Then I can use dlopen("DRIVER.so") without worrying about the details of the
path.  Or should I use a full path in the binary?

The reason to not use $(libdir) is that those modules are private to the
console client, no other application can sensefully make use of it.
The reason to include a version number seems to be common practice, and
allows for better compatibility (or lack thereof) across versions.  The use
of the one global Hurd version is as wrong as in libstore classes ;)

Is that setup fine, or do you have better suggestions?

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus <at> gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann <at> ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roland McGrath | 7 Sep 2002 00:36

Re: console plugins

It would be consistent with other modules like nss and libstore to use
/lib/console_DRIVER.so.VERSION.  Definitely use something.so.VERSION
instead of a VERSION directory, anyway.  The benefit of not using a subdir
at all (instead just a prefixed name) is that you don't need -rpath and an
unadorned name in dlopen still works.  OTOH, since this is just for one
program and not a library, a better match is perl or X server modules.
In those cases, it's some separate directory and the program does its own
path searching or whatnot to produce an absolute file name for dlopen.
Permalink | Reply | 0 comments |
headers
Warren Brian Noronha | 9 Sep 2002 19:26

Questions!

dear developers
 does hurd support alsa or any other sound drivers
 is sis 6326 supported
 is ext3 supported

 i want to be a developer for hurd i know php perl and a bit of c
 where can i find a good online tute on c

 do i need to install gnu/hurd to compile and program on hurd kernel 
 or can i do it on gnu/linux.

 keep up the good work 

Warren Brian Noronha
warren <at> freedomink.org

--

-- 

Wolfgang               ___________________________________
warren <at> freedomink.org /___/ MSN: warrennoronha <at> msn.com 
wbn.dnsq.org         /___/  YM!: warrennoronha
____________________/___/   Jab: wbn <at> jabber.org
Permalink | Reply | 0 comments |

Gmane