[OpenAFS-devel] Shipping afs/afs.h
Derrick Brashear
shadow@gmail.com
Mon, 4 Nov 2013 13:51:15 -0500
--001a11331e1a8e662104ea5e6625
Content-Type: text/plain; charset=ISO-8859-1
it shouldn't contain what it does. the whole situation is a mess though. we
need to figure out what our API *is*
and just ship that, and nothing else.
On Mon, Nov 4, 2013 at 1:37 PM, Andrew Deason <adeason@sinenomine.net>wrote:
> I've had a few people complain to me about compilation failures in
> afs/afs.h when trying to build third-party stuff that uses openafs
> libraries. One such report is RT 131737.
>
> I was kinda surprised that this is a public, shipped, header. This is
> the header that has kernel client stuff like struct vcache, struct
> vrequest, etc etc. Those are things I considered very internal, so I
> thought the header was supposed to be, too. But we do ship afs.h, and it
> looks like we've shipped it ~forever. It's always contained about the
> same contents, but builds started failing with 1.6 since the
> introduction of afs_ucred_t, as well as other refactorings.
>
> We used to have a 'struct AFS_UCRED' or something like that, where
> AFS_UCRED was #define'd to the actual cred structure when building in
> the kernel. But for 3rd-party stuff including afs.h, 'struct AFS_UCRED'
> was nothing, but an undefined structure is okay. An undefined type,
> afs_ucred_t, of course is not okay. I think there may be some other
> unavoidable errors on other platforms, but that one is the clearest.
>
> So, the problems with using this header should be clear; in my opinion,
> it seems like it should #error immediately without -DKERNEL. But what is
> this header needed for? In RT 131737 it doesn't appear to be needed for
> anything with libnss-afs. Based on another report, it appears to have
> been used to get at least "AFS_SYSCALL" and "NOPAG" in the past.
>
> "AFS_SYSCALL" should not be needed by anything anymore, since it should
> be using the platform-specific syscall mechanism and should be calling
> lpioctl() or something. "NOPAG" is returned by afs_get_pag_from_groups,
> which I don't think was intended to be public, but we don't really have
> any other interface, so some things are using it.
>
>
> So, what should the shipped afs/afs.h contain? It should at least exist,
> even if it contains nothing, so existing code that #includes it will not
> break. Does anyone know what definitions outside code may be depending
> on this file to provide? Or should it just be effectively empty, but
> provide a warning of some kind?
>
> --
> Andrew Deason
> adeason@sinenomine.net
>
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>
>
--
Derrick
--001a11331e1a8e662104ea5e6625
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">it shouldn't contain what it does. the whole situation=
is a mess though. we need to figure out what our API *is*<br>and just ship=
that, and nothing else.<br></div><div class=3D"gmail_extra"><br><br><div c=
lass=3D"gmail_quote">
On Mon, Nov 4, 2013 at 1:37 PM, Andrew Deason <span dir=3D"ltr"><<a href=
=3D"mailto:adeason@sinenomine.net" target=3D"_blank">adeason@sinenomine.net=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've had a few people complain to me about compilation failures in<br>
afs/afs.h when trying to build third-party stuff that uses openafs<br>
libraries. One such report is RT 131737.<br>
<br>
I was kinda surprised that this is a public, shipped, header. This is<br>
the header that has kernel client stuff like struct vcache, struct<br>
vrequest, etc etc. Those are things I considered very internal, so I<br>
thought the header was supposed to be, too. But we do ship afs.h, and it<br=
>
looks like we've shipped it ~forever. It's always contained about t=
he<br>
same contents, but builds started failing with 1.6 since the<br>
introduction of afs_ucred_t, as well as other refactorings.<br>
<br>
We used to have a 'struct AFS_UCRED' or something like that, where<=
br>
AFS_UCRED was #define'd to the actual cred structure when building in<b=
r>
the kernel. But for 3rd-party stuff including afs.h, 'struct AFS_UCRED&=
#39;<br>
was nothing, but an undefined structure is okay. An undefined type,<br>
afs_ucred_t, of course is not okay. I think there may be some other<br>
unavoidable errors on other platforms, but that one is the clearest.<br>
<br>
So, the problems with using this header should be clear; in my opinion,<br>
it seems like it should #error immediately without -DKERNEL. But what is<br=
>
this header needed for? In RT 131737 it doesn't appear to be needed for=
<br>
anything with libnss-afs. Based on another report, it appears to have<br>
been used to get at least "AFS_SYSCALL" and "NOPAG" in =
the past.<br>
<br>
"AFS_SYSCALL" should not be needed by anything anymore, since it =
should<br>
be using the platform-specific syscall mechanism and should be calling<br>
lpioctl() or something. "NOPAG" is returned by afs_get_pag_from_g=
roups,<br>
which I don't think was intended to be public, but we don't really =
have<br>
any other interface, so some things are using it.<br>
<br>
<br>
So, what should the shipped afs/afs.h contain? It should at least exist,<br=
>
even if it contains nothing, so existing code that #includes it will not<br=
>
break. Does anyone know what definitions outside code may be depending<br>
on this file to provide? Or should it just be effectively empty, but<br>
provide a warning of some kind?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Andrew Deason<br>
<a href=3D"mailto:adeason@sinenomine.net">adeason@sinenomine.net</a><br>
<br>
_______________________________________________<br>
OpenAFS-devel mailing list<br>
<a href=3D"mailto:OpenAFS-devel@openafs.org">OpenAFS-devel@openafs.org</a><=
br>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-devel" target=
=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-devel</a><br=
>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Derrick
</div>
--001a11331e1a8e662104ea5e6625--