any thoughts yet on a "generic" ioctl.h?

any thoughts yet on a "generic" ioctl.h?

[Robert P. J. Day]

  i asked about this a while back, but i still haven't heard a
definitive response as to whether it's acceptable.  that is, extending
the header file "asm-generic/ioctl.h" to allow arch-specific ioctl.h
header files to override what little might need to be changed from the
generic file:

==================================================
diff --git a/include/asm-generic/ioctl.h b/include/asm-generic/ioctl.h
index cd02729..e035e6d 100644
--- a/include/asm-generic/ioctl.h
+++ b/include/asm-generic/ioctl.h
@@ -21,8 +21,15 @@
  */
 #define _IOC_NRBITS	8
 #define _IOC_TYPEBITS	8
-#define _IOC_SIZEBITS	14
-#define _IOC_DIRBITS	2
+/*
+ *  Let any architecture override either of the following.
+ */
+#ifndef _IOC_SIZEBITS
+# define _IOC_SIZEBITS	14
+#endif
+#ifndef _IOC_DIRBITS
+# define _IOC_DIRBITS	2
+#endif

 #define _IOC_NRMASK	((1 << _IOC_NRBITS)-1)
 #define _IOC_TYPEMASK	((1 << _IOC_TYPEBITS)-1)
@@ -35,11 +42,17 @@
 #define _IOC_DIRSHIFT	(_IOC_SIZESHIFT+_IOC_SIZEBITS)

 /*
- * Direction bits.
+ * Direction bits, which any architecture can choose to override.
  */
-#define _IOC_NONE	0U
-#define _IOC_WRITE	1U
-#define _IOC_READ	2U
+#ifndef _IOC_NONE
+# define _IOC_NONE	0U
+#endif
+#ifndef _IOC_WRITE
+# define _IOC_WRITE	1U
+#endif
+#ifndef _IOC_READ
+# define _IOC_READ	2U
+#endif

 #define _IOC(dir,type,nr,size) \
 	(((dir)  << _IOC_DIRSHIFT) | \
========================================

  from just a cursory examination, the only values that seem to ever
need to be different are the ones mentioned above, which would make
some of those arch-specific ioctl.h files *way* shorter than they are
now.

  is this considered an acceptable kernel programming practise?  or is
it understood that, if an arch-specific header file differs *at* *all*
from the generic one, it will be a *complete* replacement for that
generic version?

rday

p.s.  i haven't looked but i'd have to guess that there are some other
header files that could be modified the same way.

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: any thoughts yet on a "generic" ioctl.h?

[Stefan Richter]

Robert P. J. Day wrote:
>   i asked about this a while back, but i still haven't heard a
> definitive response as to whether it's acceptable.

Maybe you get response if you post a complete patch.
-- 
Stefan Richter
-=====-=-=== --== -=--=
http://arcgraph.de/sr/

Re: any thoughts yet on a "generic" ioctl.h?

[Robert P. J. Day]

On Fri, 9 Mar 2007, Stefan Richter wrote:

> Robert P. J. Day wrote:
> >   i asked about this a while back, but i still haven't heard a
> > definitive response as to whether it's acceptable.
>
> Maybe you get response if you post a complete patch.

that *was* the complete patch -- its purpose was simply to make
asm-generic/ioctl.h general enough to allow arch-specific ioctl.h
files to *subsequently* be simplified.  there was no need to do
*everything* in one step -- each simplification could be submitted as
a separate arch-specific patch, as many things are.

i was more asking about the *philosophy* of that patch, and whether
there were any obvious objections.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: any thoughts yet on a "generic" ioctl.h?

[Stefan Richter]

Robert P. J. Day wrote:
> each simplification could be submitted as
> a separate arch-specific patch, as many things are.
> 
> i was more asking about the *philosophy* of that patch,

The justification of this initial patch is more obvious if followed up
by those subsequent patches which make use of the initial one.
-- 
Stefan Richter
-=====-=-=== --== --===
http://arcgraph.de/sr/

Re: any thoughts yet on a "generic" ioctl.h?

[Robert P. J. Day]

On Fri, 9 Mar 2007, Stefan Richter wrote:

> Robert P. J. Day wrote:
> > each simplification could be submitted as
> > a separate arch-specific patch, as many things are.
> >
> > i was more asking about the *philosophy* of that patch,
>
> The justification of this initial patch is more obvious if followed
> up by those subsequent patches which make use of the initial one.

  no, it's not.  i should be able to ask about the *feasibility* of a
possible simplifying patch without having to provide an actual example
of its application. if someone can't immediately see what i'm trying
to do given the previously-posted patch, then they shouldn't be
commenting on it one way or the other.

  i'm not going to go to the trouble of creating and submitting all
possible follow-up patches, only to have someone higher up the food
chain "NAK" the whole idea on philosophical grounds.  either you can
see what i'm talking about or you can't.

rday

p.s.  there is already ample predecent for what i'm asking here.  one
can submit a patch to add, say, a simplifying macro to kernel.h
without simultaneously submitting patches for everywhere it possibly
might be used.

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: any thoughts yet on a "generic" ioctl.h?

[Stefan Richter]

Robert P. J. Day wrote:
> if someone can't immediately see what i'm trying
> to do given the previously-posted patch, then they shouldn't be
> commenting on it one way or the other.

I'm not sure if you are addressing me too.  Just to clarify:  I wasn't
commenting on the patch, I only commented on what I quoted in my reply.
-- 
Stefan Richter
-=====-=-=== --== --===
http://arcgraph.de/sr/

Re: any thoughts yet on a "generic" ioctl.h?

[Robert P. J. Day]

On Fri, 9 Mar 2007, Stefan Richter wrote:

> Robert P. J. Day wrote:
> > if someone can't immediately see what i'm trying
> > to do given the previously-posted patch, then they shouldn't be
> > commenting on it one way or the other.
>
> I'm not sure if you are addressing me too.  Just to clarify:  I
> wasn't commenting on the patch, I only commented on what I quoted in
> my reply.

sorry, i worded that *really* badly.  i didn't mean to imply that
*you* were incapable of understanding what the patch represented --
i've seen enough of your posts to appreciate your technical expertise.

all i want to know is if the proposed patch making
include/asm-generic/ioctl.h more flexible is even *theoretically* a
feasible thing to do, or whether anyone on this list would have any
howling objections to it.

not only that, but i would *prefer* to submit just that file as a
first patch all by itself since, again theoretically, it shouldn't
break anything and i'd like to verify that first before trying to
simplify any of the arch-specific ioctl.h files one at a time.

as it is, the number of arch-specific ioctl.h files that could
potentially be made *much* shorter are for the arches:

  mips
  parisc
  alpha
  sparc
  sparc-64
  powerpc

all the rest simply include asm-generic/ioctl.h directly.

rday

p.s.  for those who may have come in late, the proposed new
asm-generic/ioctl.h file would allow an includer to override any or
all of:

  _IOC_SIZEBITS
  _IOC_DIRBITS
  _IOC_NONE
  _IOC_WRITE
  _IOC_READ

AFAICT, those are the only differences across the entire spectrum of
ioctl.h files.  if there's something i've missed, feel free to let me
know.

--
========================================================================
Robert P. J. Day Linux Consulting, Training and Annoying Kernel
Pedantry Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================