> I am not passing a dev_t as a binary from userspace to kernel space.Which means it is a "binary" value :)
> Its a part of the structure.
Yes, it actually is.
Exactly.
> E.g
>
> struct device_info {
>
> dev_t dev_num;
> ...
> ....
> }
Don't do that, as you have found out, it will not work.
Then just send a major and a minor number, using 2 __u16 fields instead.
> > 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.
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.
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.
The kernel having different internal structures than userspace
> > 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.
disappointed you? It shouldn't.
They are two totally different things and namespaces, and as such, have
> But I still don't understand the philosophy behind having different sizes
> for dev_t in user and kernel space.
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.
Not if you don't try to pass structures across the kernel/user boundry,
> And most importantly, its not documented and it eventually leads to silent
> corruption. Which is real difficult to trace in complex systems.
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.”
