public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* Re: [Re: [structure field names] ]
@ 2001-07-20 17:34 Eric
  2001-07-21 12:01 ` David Woodhouse
  0 siblings, 1 reply; 3+ messages in thread
From: Eric @ 2001-07-20 17:34 UTC (permalink / raw)
  To: David Woodhouse, Tim Hockin; +Cc: MTD List

David Woodhouse <dwmw2@infradead.org> wrote:
> 
> > ebrower@usa.net said:
> > > There is a patch for SPARC/Linux in the patches directory
> > > that performs 32- to 64-bit ioctl conversions.  If you
> > > touch any struct member names that are used as ioctl args
> > > this patch will need to be rev'ed as well.
> 
> I thought we'd changed the types so that conversions weren't necessary?

We changed the types so that (amongst other reasons) the ioctl
conversions were easier-- without explicitly-sized types the
conversion routines would need to redefine all structs used as
ioctl arguments to be explicitly sized, and then it would have 
to copy each struct element individually to and from userspace.

Though we are now using proper types, we still need to inform the
sparc64 kernel that the MTD ioctls are understood and require no
explicit conversions.  In the case of the MEMREADOOB and MEMWRITEOOB
ioctls, we still must do conversions so that the u8* is understood
by the kernel to be a 32-bit userspace pointer and not a 64-bit
kernelspace pointer.  This involves a bit of handwaving that will
require a conversion routine.  Strictly speaking, the sparc64 
platform does not use NAND flash so these OOB ioctls are not 
necessary (so I did not include them in the initial patch), but
DaveM would like the conversions there for completeness so I have
submitted that patch to him; if accepted, I'll submit it to the
MTD CVS for safekeeping.

To make a long story short (too late!), when running the sparc64
kernel with a 32-bit userland, ALL ioctls must have an entry in 
the ioctl32 conversion table, and some will require custom 
conversion routines.

I only brought this up because if the structure member names are
modified, they must be modified in the sparc64 patch as well.  This
is, unfortunately, a required headache.

E

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Re: [structure field names] ]
  2001-07-20 17:34 [Re: [structure field names] ] Eric
@ 2001-07-21 12:01 ` David Woodhouse
  2001-07-23 17:43   ` Tim Hockin
  0 siblings, 1 reply; 3+ messages in thread
From: David Woodhouse @ 2001-07-21 12:01 UTC (permalink / raw)
  To: Eric; +Cc: Tim Hockin, MTD List

ebrower@usa.net said:
>   In the case of the MEMREADOOB and MEMWRITEOOB ioctls, we still must
> do conversions so that the u8* is understood by the kernel to be a
> 32-bit userspace pointer and not a 64-bit kernelspace pointer. 

I don't like the MEMREADOOB and MEMWRITEOOB ioctls very much. I'm severely 
tempted to deprecate them and have a separate device for OOB space access. 
Does anyone ever actually use the /dev/mtdr<n> read-only devices?


>  I only brought this up because if the structure member names are
> modified, they must be modified in the sparc64 patch as well.  This
> is, unfortunately, a required headache.

I am sympathetic to Tim's request, but at this stage I think the pain of 
changing names probably outweighs the benefit.

--
dwmw2

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Re: [structure field names] ]
  2001-07-21 12:01 ` David Woodhouse
@ 2001-07-23 17:43   ` Tim Hockin
  0 siblings, 0 replies; 3+ messages in thread
From: Tim Hockin @ 2001-07-23 17:43 UTC (permalink / raw)
  To: David Woodhouse; +Cc: Eric, MTD List

David Woodhouse wrote:

> I am sympathetic to Tim's request, but at this stage I think the pain of
> changing names probably outweighs the benefit.

I don't think there is much risk, but that is irrelevant, since I am not
pushing it anymore :).  All I have to do is get my device working - not
necessarily understand the whole thing :)

Tim
-- 
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
thockin@sun.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-07-23 17:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-07-20 17:34 [Re: [structure field names] ] Eric
2001-07-21 12:01 ` David Woodhouse
2001-07-23 17:43   ` Tim Hockin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox