On Mon, Jul 13, 2009 at 10:57:05AM +0530, SandeepKsinha wrote:
> On Sun, Jul 12, 2009 at 11:44 PM, Greg KH <greg@xxxxxxxxx> wrote:
> > On Sun, Jul 12, 2009 at 10:16:17PM +0530, SandeepKsinha wrote:
> > > Hi,
> > > to my surprise,
> > > the sizeof dev_t differs in userspace and kernel.
> > > Its 8 bytes in userspace and 4bytes in kernel.
> > >
> > > I am working on a driver, where I include the headers in both user and
> > > kernel space.
> > > And I get wrong values due to the difference in sizes.
> > >
> > > How do I handle such a situation ?
> >
> > Why would you be passing a dev_t from user to kernel space as a binary
> > value?
> >
>
> I am not passing a dev_t as a binary from userspace to kernel space.
> Its a part of the structure.
Which means it is a "binary" value :)
> E.g
>
> struct device_info {
>
> dev_t dev_num;
> ...
> ....
> }
Exactly.
Don't do that, as you have found out, it will not work.
> > Why do you want to pass such a value across the boundry in the first
> > place?
> >
>
> This is pretty much for a custom driver, where I perform the following.
> 1. Parse the information in user space from a XML file
> 2. Do a stat on the device,
> 3. extract the device number
> 4. Fill in the structure
> 5. Pass it to the kernel driver using ioctl.
Then just send a major and a minor number, using 2 __u16 fields instead.
Within the kernel, convert it to the proper dev_t type structure, and
away you go.
> Reference: OHSM : http://code.google.com/p/fscops/
You should compare how other storage systems implement this, it is a
common problem, so you should solve it the same way.
> > Could you describe what the problem is you are trying to sove by doing
> > this?
> >
>
> Its just a part of my implementation. And I wanted to keep this uniform
> across the system.
> But having such discrepancies really disappointed me.
The kernel having different internal structures than userspace
disappointed you? It shouldn't.
> But I still don't understand the philosophy behind having different sizes
> for dev_t in user and kernel space.
They are two totally different things and namespaces, and as such, have
no requirement to be the same at all. They just happened to end up with
the same structure "name", but in reality, are not identical at all.
> And most importantly, its not documented and it eventually leads to silent
> corruption. Which is real difficult to trace in complex systems.
Not if you don't try to pass structures across the kernel/user boundry,
which this was doing :)
I would suggest using something like configfs instead of ioctls, that
way your code has a chance of getting merged. New ioctls are not
recommended to be added to the kernel at all, for this, and other
problems that you have not run into yet (32 vs. 64 bit issues are
another big one...)
good luck,
greg k-h
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
