fixed memory bytes

fixed memory bytes

[mohit verma]

hi all,
i have seen many places in  kernel where the variables specially the
structures should be of  fixed size independent of the architecture. i went
through the  definitions of them  but dint  get  clearly (or frankly  say
...dint get them even a bit) .


so ,can please someone  help me to understand this??


thanks in advance for help........
-- 
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110104/01b3c9ef/attachment.html 

fixed memory bytes

[Mulyadi Santosa]

On Wed, Jan 5, 2011 at 00:40, mohit verma <mohit89mlnc@gmail.com> wrote:
>
> hi all,
> i have seen many places in? kernel where the variables specially the
> structures should be of? fixed size independent of the architecture. i went
> through the? definitions of them? but dint? get? clearly (or frankly? say
> ...dint get them even a bit) .

Your question isn't specific enough, so I'll just guess. Let's say
"int". In 32 bit, AFAIK it's  4 byte, but in 64 bit (like IA 64, not
sure if it's x64) it's 8 byte. So, if you just say "int", you will
likely getting screwed up.

By using types like u_int or something like that, you pretty much say
"I mean 4 byte kind of integer" etc

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

fixed memory bytes

[Rajesh S R]

On Tue, Jan 4, 2011 at 11:28 PM, Mulyadi Santosa
<mulyadi.santosa@gmail.com>wrote:

> On Wed, Jan 5, 2011 at 00:40, mohit verma <mohit89mlnc@gmail.com> wrote:
> >
> > hi all,
> > i have seen many places in  kernel where the variables specially the
> > structures should be of  fixed size independent of the architecture. i
> went
> > through the  definitions of them  but dint  get  clearly (or frankly  say
> > ...dint get them even a bit) .
>
> Your question isn't specific enough, so I'll just guess. Let's say
> "int". In 32 bit, AFAIK it's  4 byte, but in 64 bit (like IA 64, not
> sure if it's x64) it's 8 byte. So, if you just say "int", you will
> likely getting screwed up.
>
> By using types like u_int or something like that, you pretty much say
> "I mean 4 byte kind of integer" etc
>

Still there can be padding issues due to byte alignment, which may vary
across architecture. Am not sure if that is controllable (probably some
pragma to gcc?). Probably, OP is asking about it?

>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Rajesh S R
http://rajeshsr.co.cc/blogs/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110104/2050762f/attachment.html 

fixed memory bytes

[mohit verma]

>
> >By using types like u_int or something like that, you pretty much say
> >"I mean 4 byte kind of integer" etc
>
that is it mulyadi. but how the compiler or kernel forces the things to get
initialized in that fixed size only independent of the architecture??

>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>



-- 
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110104/1fd16a93/attachment.html 

fixed memory bytes

[John Mahoney]

On Tue, Jan 4, 2011 at 1:07 PM, Rajesh S R <srrajesh1989@gmail.com> wrote:
>
>
> On Tue, Jan 4, 2011 at 11:28 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com>
> wrote:
>>
>> On Wed, Jan 5, 2011 at 00:40, mohit verma <mohit89mlnc@gmail.com> wrote:
>> >
>> > hi all,
>> > i have seen many places in? kernel where the variables specially the
>> > structures should be of? fixed size independent of the architecture. i
>> > went
>> > through the? definitions of them? but dint? get? clearly (or frankly
>> > say
>> > ...dint get them even a bit) .
>>
>> Your question isn't specific enough, so I'll just guess. Let's say
>> "int". In 32 bit, AFAIK it's ?4 byte, but in 64 bit (like IA 64, not
>> sure if it's x64) it's 8 byte. So, if you just say "int", you will
>> likely getting screwed up.
>>
>> By using types like u_int or something like that, you pretty much say
>> "I mean 4 byte kind of integer" etc
>
>
> Still there can be padding issues due to byte alignment, which may vary
> across architecture. Am not sure if that is controllable (probably some
> pragma to gcc?). Probably, OP is asking about it?

I believe you are referring to __attribute__( ( packed ) )

fixed memory bytes

[Mulyadi Santosa]

Hi..

On Wed, Jan 5, 2011 at 01:22, mohit verma <mohit89mlnc@gmail.com> wrote:
> that is it mulyadi. but how the compiler or kernel forces the things to get
> initialized in that fixed size only independent of the architecture??


well, AFAIK by mapping that new type into native one...for example,
let's say I have "u_int", which in turn when this code is compiled for
x86 32 bit, it is a typedef of "int".

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

fixed memory bytes

[Denis Kirjanov]

On Tue, Jan 4, 2011 at 8:40 PM, mohit verma <mohit89mlnc@gmail.com> wrote:
>
> hi all,
> i have seen many places in? kernel where the variables specially the
> structures should be of? fixed size independent of the architecture. i went
> through the? definitions of them? but dint? get? clearly (or frankly? say
> ...dint get them even a bit) .

Linux (compiler actually) supports C99 fixed-width types such as 8,
16, 32, 64 bits.
Just look through the include/linux/types.h
and small example here:
http://lxr.linux.no/#linux+v2.6.36/arch/powerpc/boot/types.h#L8
>
> so ,can please someone? help me to understand this??
>
>
> thanks in advance for help........
> --
> ........................
> MOHIT VERMA
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>



-- 
Regards,
Denis

fixed memory bytes

[John Mahoney]

Please reply all..I added back list.

On Tue, Jan 4, 2011 at 1:58 PM, mohit verma <mohit89mlnc@gmail.com> wrote:
> thnx john,.........
> but i know that this indicates to compiler to? align the structure to its
> nearest boundries. ? is that so?

I am not sure of your definition of boundary, but I would say it does
the opposite.  It tells the compiler not to align the struct to
boundaries.

--
John

fixed memory bytes

[sk.syed2]

> Linux (compiler actually) supports C99 fixed-width types such as 8,
> 16, 32, 64 bits.
> Just look through the include/linux/types.h
> and small example here:
> http://lxr.linux.no/#linux+v2.6.36/arch/powerpc/boot/types.h#L8
>>

while writing portable applications always remember that "unsigned
long" is the size of pointer and not necessarily unsigned int.

For example on x86_64 sizeof(unsigned int) != sizeof(void *).

-syed

fixed memory bytes

[julie Sullivan]

> i have seen many places in  kernel where the variables specially the
> structures should be of  fixed size independent of the architecture. i went
> through the  definitions of them  but dint  get  clearly (or frankly  say
> ...dint get them even a bit) .
>

Hi Mohit

I'm not sure whether we are interpreting your question correctly. Do you
mean

1. you've seen some code in the kernel which you think means the size of a
structure/
variable (and its resulting binary footprint) is set to be the same (in
bytes),
regardless of the architecture, and you are confused about it?

2. you think that there should be a way of fixing the structure/variable
(binary footprint)
size to be the same (in bytes) regardless of the architecture and you are
wondering if this
is possible?

In my (uninformed) opinion (2) is not be possible with the kernel due to
portability
issues - not only do natural word types differ (as others here are
explaining) but you
have no control over what optimization settings the kernel's user might set
in gcc,
for example. This is one of the problems with trying to maintain
closed-source drivers
and other binary code for the kernel, as I understand.

Thanks
Julie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110104/8cc94257/attachment.html 

fixed memory bytes

[Rajat Sharma]

A nice kernel document regarding unaligned memory access. It may not
be directly answering all the questions asked, but once gone through
and understood completely, it will become easy to figure out how to
write portable kernel code.

http://lxr.linux.no/#linux+v2.6.36/Documentation/unaligned-memory-access.txt

Rajat

On Wed, Jan 5, 2011 at 4:29 AM, julie Sullivan <kernelmail.jms@gmail.com> wrote:
>
>> i have seen many places in? kernel where the variables specially the
>> structures should be of? fixed size independent of the architecture. i went
>> through the? definitions of them? but dint? get? clearly (or frankly? say
>> ...dint get them even a bit) .
>
> Hi Mohit
>
> I'm not sure whether we are interpreting your question correctly. Do you
> mean
>
> 1. you've seen some code in the kernel which you think means the size of a
> structure/
> variable (and its resulting binary footprint) is set to be the same (in
> bytes),
> regardless of the architecture, and you are confused about it?
>
> 2. you think that there should be a way of fixing the structure/variable
> (binary footprint)
> size to be the same (in bytes) regardless of the architecture and you are
> wondering if this
> is possible?
>
> In my (uninformed) opinion (2) is not be possible with the kernel due to
> portability
> issues - not only do natural word types differ (as others here are
> explaining) but you
> have no control over what optimization settings the kernel's user might set
> in gcc,
> for example. This is one of the problems with trying to maintain
> closed-source drivers
> and other binary code for the kernel, as I understand.
>
> Thanks
> Julie
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>