i think gcc guys want to give a common abstract about "dev_t" not only
for linux kernel. So they designed the 64 bit "dev_t" and didn't want
to care about kernel's quickly changing. Maybe one day kernel's
"dev_t" will update to 64 bit. ^_^.
gcc is a compiler ,in my opinion should not be bind in one OS core.
BRs
Lin
2009/7/14 SandeepKsinha <sandeepksinha@xxxxxxxxx>:
> 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.”
>
>
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
