SYSCALL_MODULE() macro and modfind() issues

[Selphie Keller]

John,

Yes, your approach is the optimal solution for making pmap work on
both 8.1 and lower.
I wonder if there is something similiar could be done to the modfind()
function itself, but I understand that the goal of "sys/" prefix is to
reduce the conflicts and for now can use functions like your
pmap_find() to resolve the issue.

Thanks John

-Estella Mystagic (Selphie)


static int
pmap_find(void)
{
       int modid;

       modid = modfind("pmap_helper");
       if (modid == -1)
               modid = modfind("sys/pmap_helper");
       return (modid);
}

then in the original main() routine use this:

       if ((modid = pmap_find()) == -1) {

               /* module not found, try to load */
               modid  = kldload("pmap_helper.ko");
               if (modid == -1)
                       err(1, "unable to load pmap_helper module");

               modid = pmap_find();

               if (modid == -1)
                       err(1, "pmap_helper module loaded but not found");
       }

On Tue, Oct 26, 2010 at 6:31 AM, John Baldwin <jhb at freebsd.org> wrote:
> On Tuesday, October 26, 2010 3:28:10 am Andriy Gapon wrote:
>> on 26/10/2010 01:01 Selphie Keller said the following:
>> > hi fbsd-hackers,
>> >
>> > Noticed a issue in 8.1-release, 8.1p1-release and 8.1-stable
>> > amd64/i386, to where modfind() will no longer find pmap_helper for the
>> > /usr/ports/sysutils/pmap port, or other syscall modules using
>> > SYSCALL_MODULE() macro.
>> > The issue is that modfind() function no longer finds any modules using
>> > SYSCALL_MODULE() macro to register the kernel module. Making it
>> > difficult for userland apps to call the syscall provided. modfind()
>> > always returns -1 which prevents modstat() from getting the required
>> > information to perform the syscall.
>> >
>> > Also tested, the demo syscall module:
>>
>> After commit r205320 and, apparently, its MFC you need to prefix the module with
>> "sys/".  For example:
>> modstat(modfind("sys/syscall"), &stat);
>>
>> P.S.
>> Perhaps a KPI breakage in a stable branch?
>
> Ugh, it was a breakage though it's too late to back it out at this point.
>
> --
> John Baldwin
>