Hi Greg,
> 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 :)
>
Yes, it actually is.
>
> > 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.
>
Yes, this can be one of the way to achieve it.
>
> > 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.
>
True. I shall have a look at it.
>
> > > 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.
>
Well, for most of the kernel subsystems you will have a client in userspace
and they surely need to communicate.
So, there should surely be some handshake.
>
> > 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
>
I shall take care of that.
Thanks again.
Regards,
Sandeep.
“To learn is to change. Education is a process that changes the learner.”
