Bug#627947: libkafs0-heimdal: k_hasafs always returns false
On Sat, 28 May 2011 12:46:05 -0500 Pino Toscano toscano.p...@tiscali.it wrote: Oh, sorry if it broke something, it was not intended. It part of the original patch set done by Samuel, which I trusted (as he is a Hurd developer and Debian/Hurd maintainer). Oh, certainly. These things happen :) - do the semi-ugly solution an define VIOC_SYSCALL_PROC differently on Hurd (see also [1], missing _IOT section, for an explanation of what can and cannot be done in ioctl's on Hurd). I attached a new version of patch 043_hurd_ioctl. Sure, it looks like that will work. From the perspective of OpenAFS and other AFS implementations, it is a little annoying to have to make a special case for Hurd for the ioctl number if and when Hurd support is added... but I'd expect a lot of things to require Hurd special-cases, anyway. Will this be sent to Heimdal upstream, btw? This probably would have gotten noticed sooner if this had been sent there, and I don't know if they have opinions on this. [1] http://www.gnu.org/s/hurd/hurd/porting/guidelines.html Thanks! -- Andrew Deason adea...@sinenomine.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627947: libkafs0-heimdal: k_hasafs always returns false
On 29 May 2011 16:35, Andrew Deason adea...@sinenomine.net wrote: Oh, certainly. These things happen :) Agreed. Just rebuilding Heimdal with the new patch now. - do the semi-ugly solution an define VIOC_SYSCALL_PROC differently on Hurd (see also [1], missing _IOT section, for an explanation of what can and cannot be done in ioctl's on Hurd). I attached a new version of patch 043_hurd_ioctl. Sure, it looks like that will work. From the perspective of OpenAFS and other AFS implementations, it is a little annoying to have to make a special case for Hurd for the ioctl number if and when Hurd support is added... but I'd expect a lot of things to require Hurd special-cases, anyway. For references, there is also the following bug that discusses AFS with Heimdal: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324342 and this even older bug report for The Hurd support: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=113317 Will this be sent to Heimdal upstream, btw? This probably would have gotten noticed sooner if this had been sent there, and I don't know if they have opinions on this. Do you think The Hurd patches are of sufficient quality to be submitted upstream? -- Brian May br...@microcomaustralia.com.au
Bug#627947: libkafs0-heimdal: k_hasafs always returns false
Hello Pino,
As the contributor of the patch being discussed, can I please get your
opinion on this bug report?
Thanks
On 26 May 2011 04:44, Andrew Deason adea...@sinenomine.net wrote:
k_hasafs is currently broken, due to patch 043_hurd_ioctl introduced in
1.4.0-4 to fix #483281. That patch changes the definition of
VIOC_SYSCALL_PROC in this hunk:
-#define VIOC_SYSCALL_PROC _IOW('C', 1, void *)
+#ifdef __GNU__
+#define _IOT_procdata _IOT(_IOTS(long), 5, 0, 0, 0, 0)
+#endif
+#define VIOC_SYSCALL_PROC _IOW('C', 1, struct procdata)
This changes the ioctl command number we use to an incorrect one, so
k_hasafs() always returns false, even if an AFS client is running. I
have no idea what GNU hurd uses _IOT_* for, but since _IOT_procdata
includes the name of a structure, I expect that this will FTBFS on hurd
again if the third _IOW argument is just reverted to void*.
I don't know if the GNU hurd folks have an opinion on the proper
solution here, but here are a couple of options that I think will work:
- Define a structure that only has one 'void*' in it, and pass that in
instead of struct procdata. (And define _IOT_whatever instead of
_IOT_procdata
- Don't build kafs on hurd, or just always return 0 for k_hasafs or
something, since I'm not aware of any AFS kernel clients that run on
hurd. In particular, trying to calculate the ioctl number on hurd
doesn't make a lot of sense, since there's never any kernel module on
hurd to match it to. There's no correct number.
--
Brian May br...@microcomaustralia.com.au
Bug#627947: libkafs0-heimdal: k_hasafs always returns false
Hi Brain,
Alle sabato 28 maggio 2011, Brian May ha scritto:
As the contributor of the patch being discussed, can I please get
your opinion on this bug report?
Oh, sorry if it broke something, it was not intended. It part of the
original patch set done by Samuel, which I trusted (as he is a Hurd
developer and Debian/Hurd maintainer).
I don't know if the GNU hurd folks have an opinion on the proper
solution here, but here are a couple of options that I think will
work:
- do the semi-ugly solution an define VIOC_SYSCALL_PROC differently on
Hurd (see also [1], missing _IOT section, for an explanation of what
can and cannot be done in ioctl's on Hurd). I attached a new version of
patch 043_hurd_ioctl.
(to be honest, it would seem kind of weird to declare a void* as
argument, while ioctl's in that file for devdata eclare explicitly the
struct; I guess this is something that cannot be changed easily due to
being already in use)
[1] http://www.gnu.org/s/hurd/hurd/porting/guidelines.html
Sorry again for the breakage, luckly has never been part of a stable
release.
--
Pino Toscano
--- a/lib/kafs/kafs.h
+++ b/lib/kafs/kafs.h
@@ -46,6 +46,9 @@
#define AFSCALL_SETPAG 21
#ifndef _VICEIOCTL
+#ifdef __GNU__
+#define _IOT_ViceIoctl _IOT(_IOTS(caddr_t), 2, _IOTS(short), 2, 0, 0)
+#endif
#define _VICEIOCTL(id) ((unsigned int ) _IOW('V', id, struct ViceIoctl))
#define _AFSCIOCTL(id) ((unsigned int ) _IOW('C', id, struct ViceIoctl))
#endif /* _VICEIOCTL */
--- a/lib/kafs/afssys.c
+++ b/lib/kafs/afssys.c
@@ -40,7 +40,12 @@ struct procdata {
unsigned long param1;
unsigned long syscall;
};
+#ifdef __GNU__
+#define _IOT_procdata _IOT(_IOTS(long), 5, 0, 0, 0, 0)
+#define VIOC_SYSCALL_PROC _IOW('C', 1, struct procdata)
+#else
#define VIOC_SYSCALL_PROC _IOW('C', 1, void *)
+#endif
struct devdata {
unsigned long syscall;
@@ -52,6 +57,9 @@ struct devdata {
unsigned long param6;
unsigned long retval;
};
+#ifdef __GNU__
+#define _IOT_devdata _IOT(_IOTS(long), 8, 0, 0, 0, 0)
+#endif
#ifdef _IOWR
#define VIOC_SYSCALL_DEV _IOWR('C', 2, struct devdata)
#define VIOC_SYSCALL_DEV_OPENAFS _IOWR('C', 1, struct devdata)
signature.asc
Description: This is a digitally signed message part.
Bug#627947: libkafs0-heimdal: k_hasafs always returns false
Package: libkafs0-heimdal
Version: 1.4.0-5
k_hasafs is currently broken, due to patch 043_hurd_ioctl introduced in
1.4.0-4 to fix #483281. That patch changes the definition of
VIOC_SYSCALL_PROC in this hunk:
-#define VIOC_SYSCALL_PROC _IOW('C', 1, void *)
+#ifdef __GNU__
+#define _IOT_procdata _IOT(_IOTS(long), 5, 0, 0, 0, 0)
+#endif
+#define VIOC_SYSCALL_PROC _IOW('C', 1, struct procdata)
This changes the ioctl command number we use to an incorrect one, so
k_hasafs() always returns false, even if an AFS client is running. I
have no idea what GNU hurd uses _IOT_* for, but since _IOT_procdata
includes the name of a structure, I expect that this will FTBFS on hurd
again if the third _IOW argument is just reverted to void*.
I don't know if the GNU hurd folks have an opinion on the proper
solution here, but here are a couple of options that I think will work:
- Define a structure that only has one 'void*' in it, and pass that in
instead of struct procdata. (And define _IOT_whatever instead of
_IOT_procdata
- Don't build kafs on hurd, or just always return 0 for k_hasafs or
something, since I'm not aware of any AFS kernel clients that run on
hurd. In particular, trying to calculate the ioctl number on hurd
doesn't make a lot of sense, since there's never any kernel module on
hurd to match it to. There's no correct number.
--
Andrew Deason
adea...@sinenomine.net
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
