This is the mail archive of the mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RFC: NSS prototypes


On Mon, Dec 18, Ulrich Drepper wrote:

> Andreas Jaeger <> writes:
> > nis/nss_nis/nis-netgrp.c uses:
> > enum nss_status
> > _nss_nis_setnetgrent (const char *group)
> > 
> > but nss/nss_files/files-netgrp.c has:
> > enum nss_status
> > _nss_files_setnetgrent (const char *group, struct __netgrent *result)
> Well, I've implemented only the files part.  Thorsten then did the NIS
> part.  You should ask him why he does not need the result data
> pointer.  The function is called in __internal_setnetgrent_reuse with
> the extra parameter.

I could use them, but struct __netgrent can only handle the case 
where you have one module in the /etc/nsswitch.conf netgroup line,
not more. One module will overwrite the data from the previous
We would need a list with a unique id for every module and a pointer
to the data the module needs.

I work in all modules with static data and a lock, because the NIS
and RPC interface is not reentrant. I don't know why we haven't 
changed it, but for me it doesn't make any difference.


Thorsten Kukuk
SuSE GmbH            Schanzaeckerstr. 10            90443 Nuernberg
Linux is like a Vorlon.  It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]