Re: do_initcalls
On Tue, 19 Mar 2013, ishare wrote: > > /** > > * module_init() - driver initialization entry point > > * @x: function to be run at kernel boot time or module insertion > > * > > * module_init() will either be called during do_initcalls() (if > > * builtin) or at module insertion time (if a module). There can only > > * be one per module. > > */ > >Does this mean it chould not be called during do_initcalls if I config it > as a module ? > do_initcalls() is done at boot time. If you insert a module into the running kernel, how could its init function be called at boot time? >If this ,how to change it to be builtin module? > Whether it is compiled as a module or not is a configuration issue. (Please, CMIIW). >what is called module insertion time? Is that time I explicitely call > some insert function? > I hope I got your question right (no, I hope I didn't but anyway here's my answer to it): module insertion time is precisely the time a module is inserted. You'd normally use modprobe or suchlike for this task. As the comment above states, the function registered via module_init() is called by the kernel's dynamic linker at this point. I suggest to afford some of the well-known books on the Linux kernel. I believe you can't avoid to do so when trying around with the kernel. Regards, Tobi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Design Patterns in Linux Kernel: Fancy Tricks With Linked Lists
On Tue, 19 Mar 2013, Arlie Stephens wrote: > Hi Robert, > > Thank you very much - for your web pages as well as for your responses > in this thread. > > On Mar 19 2013, Robert P. J. Day wrote: > >Oh, crap, I just remembered that even Robert Love's 3rd edition of > > "Linux Kernel Development" (aka "LKD3") isn't 100% correct WRT linked > > lists. A while back, I started keeping track of typoes/errors/whatever > > in LKD3 for the benefit of the eventual LKD4, and I started a page here: > > > > http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3 > > > >Partway down that page, you can see my notes on linked lists: > > > > http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3#Linked_lists > > Beautiful! This page covers everything we were confused about > yesterday. And you are right - I read Love's 3rd edition as more > ambiguous than wrong, but he does say the "head" node is not a member > of the list, and that's more wrong than ambiguous. Morevover, the > biggest problem with my first implementation was that I believed him. glad i could help. i have plenty of wiki pages, a lot of which are probably junk by now that could use either deleting or updating. when i finish my current contract, i'll take a week and rip all of that apart and put it back together properly. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Design Patterns in Linux Kernel: Fancy Tricks With Linked Lists
On Tue, Mar 19, 2013 at 8:50 PM, Victor Buciuc wrote: > On Tue, Mar 19, 2013 at 5:34 PM, Arlie Stephens wrote: >> Hi Folks, >> >> I'm trying to understand the linux way of doing things, so as to write >> code which will be easier for experienced linux kernel people to >> understand. Yesterday I wound up in a 3 engineer discussion about >> something conceptually simple, that just didn't want to be done with >> the tools at hand; what's worse, the only ways I could see to do it >> were (a) do my own linked lists or (b) write some routines that relied >> kind of heavily on the never-mentioned-in-documentation details of >> linux/list.h I'll probably go with option (b), as that seems less >> insane, but I thought I might as well ask here as well. >> >> Here's the problem. I have a collection of resources. Call them >> A,B,C,D but note that resources get added at run time, so I don't know >> how many to expect. I want to go through them in a round robin >> fashion, but not all at once. On the first request, I use A. On a >> later request I use B, etc. This seems to me to map naturally to a >> circular linked list, with a "cursor" - a pointer of some kind to the >> next one I want to use. To make my specific situation more >> interesting, I actually have multiple cursors - that may or may not >> happen to point to the same node at any given time, but usually will >> not. >> >> This is where I wish I could draw pictures in ascii emails ;-) >> Perhaps the following will come through halfway sanely: >> >> C1 C2 C3 >> V /V >> A<->B<->C-<->D >> ^^ >> > > Hi, > > Another option might be to not iterate through the list but to simply > move the element you're processing to the end of the list using > list_rotate_left[1]. > And you could use list_next_entry[2] to get the next entry after the > head. You'll > have to check that the list is empty, tough. > > This would cost you some extra operations but you'll use the existing > interface. > > [1] http://lxr.linux.no/linux+v3.8.3/include/linux/list.h#L214 > [2] http://lxr.linux.no/linux+v3.8.3/include/linux/list.h#L361 > > Regards, > Victor Buciuc. Forgot to send to the list. Regards, Victor Buciuc. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Design Patterns in Linux Kernel: Fancy Tricks With Linked Lists
Hi Robert, Thank you very much - for your web pages as well as for your responses in this thread. On Mar 19 2013, Robert P. J. Day wrote: >Oh, crap, I just remembered that even Robert Love's 3rd edition of > "Linux Kernel Development" (aka "LKD3") isn't 100% correct WRT linked > lists. A while back, I started keeping track of typoes/errors/whatever > in LKD3 for the benefit of the eventual LKD4, and I started a page here: > > http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3 > >Partway down that page, you can see my notes on linked lists: > > http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3#Linked_lists Beautiful! This page covers everything we were confused about yesterday. And you are right - I read Love's 3rd edition as more ambiguous than wrong, but he does say the "head" node is not a member of the list, and that's more wrong than ambiguous. Morevover, the biggest problem with my first implementation was that I believed him. -- Arlie (Arlie Stephens ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Design Patterns in Linux Kernel: Fancy Tricks With Linked Lists
Quoting "Robert P. J. Day" : > Quoting Arlie Stephens : > >> Interestingly, part of the debate yesterday probably resulted from one >> engineer having Love's 2nd edition, and me having his 3rd >> edition. Apparently RPDay pointed out some problems to Love which >> resulted in him changing his linked list discussion in his 3rd >> edition ;-) > >Been a while since I re-read my own tutorial, it might merit a bit of > a rewrite. Is there anything about it that seems unclear -- I remember > my own moment of epiphany, "Holy crap, what an interesting way to do it." > >And, yes, if you try to reconcile Love's 2nd and 3rd editions on the > topic, that will not end well. :-) Oh, crap, I just remembered that even Robert Love's 3rd edition of "Linux Kernel Development" (aka "LKD3") isn't 100% correct WRT linked lists. A while back, I started keeping track of typoes/errors/whatever in LKD3 for the benefit of the eventual LKD4, and I started a page here: http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3 Partway down that page, you can see my notes on linked lists: http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3#Linked_lists I'm going to have to review what I wrote there to remember why I wrote it but, from a cursory glance, it appears that I still had complaints about the presentation in LKD3. So feel free to read that wiki section in conjunction with LKD3 to figure out what I was babbling about. rday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Design Patterns in Linux Kernel: Fancy Tricks With Linked Lists
Quoting Arlie Stephens : > Interestingly, part of the debate yesterday probably resulted from one > engineer having Love's 2nd edition, and me having his 3rd > edition. Apparently RPDay pointed out some problems to Love which > resulted in him changing his linked list discussion in his 3rd > edition ;-) Been a while since I re-read my own tutorial, it might merit a bit of a rewrite. Is there anything about it that seems unclear -- I remember my own moment of epiphany, "Holy crap, what an interesting way to do it." And, yes, if you try to reconcile Love's 2nd and 3rd editions on the topic, that will not end well. :-) rday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: for interested folks, i'll announce new kernel tutorials via twitter
Keep the tutorials coming sir, would be very cool to read and pass along to others who are also interested to start hacking around on the kernel. Kudos to you! On Sun, Mar 17, 2013 at 9:37 PM, Robert P. J. Day wrote: > > as i don't want to seem like i'm spamming this list with notes about > new, posted kernel tutorials, people who want to stay on top of these > are welcome to follow me on twitter at @rpjday. everything written and > posted will be freely available (creative commons license), and even > after it's incorporated into future training courses, even those > courses will be released under the CC so you'll never lose access to > any of it. so feel free to play along. > > rday > > -- > > > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- I don't Yahoo! anymore :-) Yehey! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Design Patterns in Linux Kernel: Fancy Tricks With Linked Lists
Hi Dave,
Thank you very much.
On Mar 19 2013, Dave Hylands wrote:
>
> Hi Arlie,
>
[SNIP]
> So the real secret is that it's a circular list with a dummy node. This
> dummy node just has head/tail pointers and nothing else.
It's good to have confirmation of this.
>
> So when you're advancing through the list, instead of testing list->next
> for NULL you check to see if list->next is equal to the list head.
>
> So if you want your cursor object to be self-contained, then it should
> include both a list head and a list current.
>
> If you want your cursor to be generic, then it should probably look
> something like:
>
> struct list_cursor {
> struct list_head *list;
> struct list_head *curr;
> };
>
> I think you'll find that the cursor operations make a lot more sense if you
> keep the cursor generic and try not to include the type information about
> the list node.
And this feels right, in a way that what I was doing did not.
>
> To initialize the cursor:
>
> cursor->list = somelist
> cursor->curr = somelist
>
> To advance to the first node (remember the list has a dummy head node)
>
> cursor->curr = cursor->curr->next
>
> If the result is == cursor->head then there aren't any nodes except for the
> dummy node (i.e. list is empty)
>
> To get at the actual entry, use list_entry as per usual.
>
> I see RPDay has posted the link to his little tutorial, and I was going to
> do the same, but I didn't have it saved anywhere. I highly recommend
> reading through that.
Good introduction. And a great link at the end.
Interestingly, part of the debate yesterday probably resulted from one
engineer having Love's 2nd edition, and me having his 3rd
edition. Apparently RPDay pointed out some problems to Love which
resulted in him changing his linked list discussion in his 3rd
edition ;-)
--
Arlie
(Arlie Stephens ar...@worldash.org)
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Design Patterns in Linux Kernel: Fancy Tricks With Linked Lists
On Tue, Mar 19, 2013 at 3:53 PM, Dave Hylands wrote:
> Hi Arlie,
>
>
>
> On Tue, Mar 19, 2013 at 8:34 AM, Arlie Stephens
> wrote:
> >
> > Hi Folks,
> >
> > I'm trying to understand the linux way of doing things, so as to write
> > code which will be easier for experienced linux kernel people to
> > understand. Yesterday I wound up in a 3 engineer discussion about
> > something conceptually simple, that just didn't want to be done with
> > the tools at hand; what's worse, the only ways I could see to do it
> > were (a) do my own linked lists or (b) write some routines that relied
> > kind of heavily on the never-mentioned-in-documentation details of
> > linux/list.h I'll probably go with option (b), as that seems less
> > insane, but I thought I might as well ask here as well.
> >
> > Here's the problem. I have a collection of resources. Call them
> > A,B,C,D but note that resources get added at run time, so I don't know
> > how many to expect. I want to go through them in a round robin
> > fashion, but not all at once. On the first request, I use A. On a
> > later request I use B, etc. This seems to me to map naturally to a
> > circular linked list, with a "cursor" - a pointer of some kind to the
> > next one I want to use. To make my specific situation more
> > interesting, I actually have multiple cursors - that may or may not
> > happen to point to the same node at any given time, but usually will
> > not.
> >
> > This is where I wish I could draw pictures in ascii emails ;-)
> > Perhaps the following will come through halfway sanely:
> >
> > C1 C2 C3
> > V /V
> > A<->B<->C-<->D
> > ^^
> >
> > list.h implements a circular linked list - see for example
> > http://www.makelinux.net/books/lkd2/app01lev1sec2 - so I thought this
> > would be easy and natural. But then I discovered there was no such
> > thing as a list_next(). OK, I can write it - Something like:
> > cursor->resource = list_entry(cursor->resource->link.next, struct
> resource, link);
> > But the fact there was no interface made me ask advice from colleagues.
> > And that's when the debate erupted.
> >
> > First of all, it's unclear whether that would even work. If the list
> > is initialized following the standard pardigm, there may be a "head"
> > element embedded in the list, which all the existing interfaces know
> > to ignore. I.e.
>
> So the real secret is that it's a circular list with a dummy node. This
> dummy node just has head/tail pointers and nothing else.
>
> So when you're advancing through the list, instead of testing list->next
> for NULL you check to see if list->next is equal to the list head.
>
> So if you want your cursor object to be self-contained, then it should
> include both a list head and a list current.
>
> If you want your cursor to be generic, then it should probably look
> something like:
>
> struct list_cursor {
> struct list_head *list;
> struct list_head *curr;
> };
>
> I think you'll find that the cursor operations make a lot more sense if
> you keep the cursor generic and try not to include the type information
> about the list node.
>
> To initialize the cursor:
>
> cursor->list = somelist
> cursor->curr = somelist
>
> To advance to the first node (remember the list has a dummy head node)
>
> cursor->curr = cursor->curr->next
>
> If the result is == cursor->head then there aren't any nodes except for
> the dummy node (i.e. list is empty)
>
> To get at the actual entry, use list_entry as per usual.
>
> I see RPDay has posted the link to his little tutorial, and I was going to
> do the same, but I didn't have it saved anywhere. I highly recommend
> reading through that.
>
> Besides the Robert's link you can also have a look at FAQ on kernel newbies
http://kernelnewbies.org/FAQ/LinkedLists
LDD also covers it
http://www.makelinux.net/ldd3/chp-11-sect-5
There is a good explanation of kernel linked list in Robert Love's book as
well.
--
> Dave Hylands
> Shuswap, BC, Canada
> http://www.davehylands.com
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
--
Thank you
Warm Regards
Anuz
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Memory allocations in linux for processes
On Tue, 19 Mar 2013 20:41:55 +0530, Niroj Pokhrel said:
> #include
> int main()
> {
> while(1)
> {
> }
> return 0;
> }
>
> I don't understand where does mmap or malloc come in to play in this code.
Unless you linked it statically, a lot of stuff happens before you ever
get to main() - namely, any shared library linking and mapping. Run
strace on your binary and see how many system calls happen before you hit
the infinite loop.
pgpjT3sQt6KU0.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Design Patterns in Linux Kernel: Fancy Tricks With Linked Lists
Hi Arlie,
On Tue, Mar 19, 2013 at 8:34 AM, Arlie Stephens wrote:
>
> Hi Folks,
>
> I'm trying to understand the linux way of doing things, so as to write
> code which will be easier for experienced linux kernel people to
> understand. Yesterday I wound up in a 3 engineer discussion about
> something conceptually simple, that just didn't want to be done with
> the tools at hand; what's worse, the only ways I could see to do it
> were (a) do my own linked lists or (b) write some routines that relied
> kind of heavily on the never-mentioned-in-documentation details of
> linux/list.h I'll probably go with option (b), as that seems less
> insane, but I thought I might as well ask here as well.
>
> Here's the problem. I have a collection of resources. Call them
> A,B,C,D but note that resources get added at run time, so I don't know
> how many to expect. I want to go through them in a round robin
> fashion, but not all at once. On the first request, I use A. On a
> later request I use B, etc. This seems to me to map naturally to a
> circular linked list, with a "cursor" - a pointer of some kind to the
> next one I want to use. To make my specific situation more
> interesting, I actually have multiple cursors - that may or may not
> happen to point to the same node at any given time, but usually will
> not.
>
> This is where I wish I could draw pictures in ascii emails ;-)
> Perhaps the following will come through halfway sanely:
>
> C1 C2 C3
> V /V
> A<->B<->C-<->D
> ^^
>
> list.h implements a circular linked list - see for example
> http://www.makelinux.net/books/lkd2/app01lev1sec2 - so I thought this
> would be easy and natural. But then I discovered there was no such
> thing as a list_next(). OK, I can write it - Something like:
> cursor->resource = list_entry(cursor->resource->link.next, struct
resource, link);
> But the fact there was no interface made me ask advice from colleagues.
> And that's when the debate erupted.
>
> First of all, it's unclear whether that would even work. If the list
> is initialized following the standard pardigm, there may be a "head"
> element embedded in the list, which all the existing interfaces know
> to ignore. I.e.
So the real secret is that it's a circular list with a dummy node. This
dummy node just has head/tail pointers and nothing else.
So when you're advancing through the list, instead of testing list->next
for NULL you check to see if list->next is equal to the list head.
So if you want your cursor object to be self-contained, then it should
include both a list head and a list current.
If you want your cursor to be generic, then it should probably look
something like:
struct list_cursor {
struct list_head *list;
struct list_head *curr;
};
I think you'll find that the cursor operations make a lot more sense if you
keep the cursor generic and try not to include the type information about
the list node.
To initialize the cursor:
cursor->list = somelist
cursor->curr = somelist
To advance to the first node (remember the list has a dummy head node)
cursor->curr = cursor->curr->next
If the result is == cursor->head then there aren't any nodes except for the
dummy node (i.e. list is empty)
To get at the actual entry, use list_entry as per usual.
I see RPDay has posted the link to his little tutorial, and I was going to
do the same, but I didn't have it saved anywhere. I highly recommend
reading through that.
--
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Design Patterns in Linux Kernel: Fancy Tricks With Linked Lists
Quoting Arlie Stephens : > Hi Folks, > > I'm trying to understand the linux way of doing things, so as to write > code which will be easier for experienced linux kernel people to > understand. Yesterday I wound up in a 3 engineer discussion about > something conceptually simple, that just didn't want to be done with > the tools at hand; what's worse, the only ways I could see to do it > were (a) do my own linked lists or (b) write some routines that relied > kind of heavily on the never-mentioned-in-documentation details of > linux/list.h I'll probably go with option (b), as that seems less > insane, but I thought I might as well ask here as well. ... snip ... http://crashcourse.ca/introduction-linux-kernel-programming/intermission-lets-talk-about-linked-lists-and-containerof-free rday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Design Patterns in Linux Kernel: Fancy Tricks With Linked Lists
Hi Folks, I'm trying to understand the linux way of doing things, so as to write code which will be easier for experienced linux kernel people to understand. Yesterday I wound up in a 3 engineer discussion about something conceptually simple, that just didn't want to be done with the tools at hand; what's worse, the only ways I could see to do it were (a) do my own linked lists or (b) write some routines that relied kind of heavily on the never-mentioned-in-documentation details of linux/list.h I'll probably go with option (b), as that seems less insane, but I thought I might as well ask here as well. Here's the problem. I have a collection of resources. Call them A,B,C,D but note that resources get added at run time, so I don't know how many to expect. I want to go through them in a round robin fashion, but not all at once. On the first request, I use A. On a later request I use B, etc. This seems to me to map naturally to a circular linked list, with a "cursor" - a pointer of some kind to the next one I want to use. To make my specific situation more interesting, I actually have multiple cursors - that may or may not happen to point to the same node at any given time, but usually will not. This is where I wish I could draw pictures in ascii emails ;-) Perhaps the following will come through halfway sanely: C1 C2 C3 V /V A<->B<->C-<->D ^^ list.h implements a circular linked list - see for example http://www.makelinux.net/books/lkd2/app01lev1sec2 - so I thought this would be easy and natural. But then I discovered there was no such thing as a list_next(). OK, I can write it - Something like: cursor->resource = list_entry(cursor->resource->link.next, struct resource, link); But the fact there was no interface made me ask advice from colleagues. And that's when the debate erupted. First of all, it's unclear whether that would even work. If the list is initialized following the standard pardigm, there may be a "head" element embedded in the list, which all the existing interfaces know to ignore. I.e. LIST_HEAD(resources); add_resource(...) new_resource = kmalloc(sizeof(struct resource), GFP_KERNEL); new_resource->ID = ... INIT_LIST_HEAD(&new_resource->link); list_add(&new_resource->link, &resources) It looks as if the circular list is likely to include the variable named 'resources', so new_resource->link.next might point to resources, and list_entry(new_resource->link.next, struct resource, link) might point to whatever unrelated variable happens to be somewhere near 'resources'. It's certain that the implementation makes no attempt to clarify what kind of list it's using ... not when we had 3 experienced engineers draw 2 different conclusions, one changing his mind midway. Obviously I can figure out what the link.h implementation actually does, and code accordingly. That's my plan for this morning. I'm just not sure it's going to produce code that other engineers will be comfortable maintaining. And if they aren't comfortable, there will be uneccessary bugs. So, how would a dyed-in-the-wool linux kernel engineer approach this task? I.e. what's the natural design pattern here, within linux? I think it's pretty clear that the one I've come up with seems so unnatural to the authors of list.h that they never even imagined it. Thanks for any insights, -- Arlie (Arlie Stephens ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Memory allocations in linux for processes
On Tue, Mar 19, 2013 at 8:27 PM, Mulyadi Santosa
wrote:
> Hi Niroj
>
> Please see inlined answer below...
>
> On Mon, Mar 18, 2013 at 5:28 PM, Niroj Pokhrel
> wrote:
> > Hi all,
> > As I have read, whenever we execute a program, the memory is allocated in
> > different sections viz stack, text and data segment.
>
> Yup, that is correct
>
> > But, since we have used
> > loader and linker the three allocations will happen for them too.
>
> Correct again. Linker and loader will be the part of process address space.
>
> > But when I ran a program and did pmap pid, I saw several other fields
> which
> > I have no idea of. What is the [anon] and what is it doing here ?
>
> Anon is short of anonymous. It is a region of memory created by
> function e.g malloc() or mmap()
>
> >Why the
> > memory is being implemented for it and there are so many of them ?
>
> Drawing from above explanation, we can easily conclude somewhere in
> the program, it does malloc() or mmap().
>
> > And also the stack ( 3rd last element), is it the process stack??
>
> Yes, it's process' stack
>
> >Can
> > somebody please explain.
> > Thanking you all in advance.
> >
> > 5448: ./a.out
> > 0040 4K r-x-- /home/n.pokhrel/Personal/mywork/a.out
> > 0060 4K r /home/n.pokhrel/Personal/mywork/a.out
> > 00601000 4K rw--- /home/n.pokhrel/Personal/mywork/a.out
> > 7f57f5e18000 1512K r-x-- /lib/libc-2.11.1.so
> > 7f57f5f92000 2044K - /lib/libc-2.11.1.so
> > 7f57f6191000 16K r /lib/libc-2.11.1.so
> > 7f57f6195000 4K rw--- /lib/libc-2.11.1.so
> > 7f57f6196000 20K rw---[ anon ]
> > 7f57f619b000128K r-x-- /lib/ld-2.11.1.so
> > 7f57f6396000 12K rw---[ anon ]
> > 7f57f63b8000 8K rw---[ anon ]
> > 7f57f63ba000 4K r /lib/ld-2.11.1.so
> > 7f57f63bb000 4K rw--- /lib/ld-2.11.1.so
> > 7f57f63bc000 4K rw---[ anon ]
> > 7fffa2f37000 84K rw---[ stack ]
>
> > 7fffa2fa 4K r-x--[ anon ]
> > ff60 4K r-x--[ anon ]
>
> ok, one of the region above, I think it's VDSO (virtual dynamic shared
> object). It's a region that handle system call. When a process does
> system call, it jumps to VDSO, and it is the VDSO that does the
> actuall syscall
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
Hi Mulyadi .
Thank you very much But I still have a minor confusion .
All I ran was this short program
#include
int main()
{
while(1)
{
}
return 0;
}
I don't understand where does mmap or malloc come in to play in this code.
It would be great if you can give me some insight.
Thanking you in advance.
Yours,
Niroj Pokhrel
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Memory allocations in linux for processes
Hi Niroj Please see inlined answer below... On Mon, Mar 18, 2013 at 5:28 PM, Niroj Pokhrel wrote: > Hi all, > As I have read, whenever we execute a program, the memory is allocated in > different sections viz stack, text and data segment. Yup, that is correct > But, since we have used > loader and linker the three allocations will happen for them too. Correct again. Linker and loader will be the part of process address space. > But when I ran a program and did pmap pid, I saw several other fields which > I have no idea of. What is the [anon] and what is it doing here ? Anon is short of anonymous. It is a region of memory created by function e.g malloc() or mmap() >Why the > memory is being implemented for it and there are so many of them ? Drawing from above explanation, we can easily conclude somewhere in the program, it does malloc() or mmap(). > And also the stack ( 3rd last element), is it the process stack?? Yes, it's process' stack >Can > somebody please explain. > Thanking you all in advance. > > 5448: ./a.out > 0040 4K r-x-- /home/n.pokhrel/Personal/mywork/a.out > 0060 4K r /home/n.pokhrel/Personal/mywork/a.out > 00601000 4K rw--- /home/n.pokhrel/Personal/mywork/a.out > 7f57f5e18000 1512K r-x-- /lib/libc-2.11.1.so > 7f57f5f92000 2044K - /lib/libc-2.11.1.so > 7f57f6191000 16K r /lib/libc-2.11.1.so > 7f57f6195000 4K rw--- /lib/libc-2.11.1.so > 7f57f6196000 20K rw---[ anon ] > 7f57f619b000128K r-x-- /lib/ld-2.11.1.so > 7f57f6396000 12K rw---[ anon ] > 7f57f63b8000 8K rw---[ anon ] > 7f57f63ba000 4K r /lib/ld-2.11.1.so > 7f57f63bb000 4K rw--- /lib/ld-2.11.1.so > 7f57f63bc000 4K rw---[ anon ] > 7fffa2f37000 84K rw---[ stack ] > 7fffa2fa 4K r-x--[ anon ] > ff60 4K r-x--[ anon ] ok, one of the region above, I think it's VDSO (virtual dynamic shared object). It's a region that handle system call. When a process does system call, it jumps to VDSO, and it is the VDSO that does the actuall syscall -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kernel build error
Hi ... On Tue, Mar 19, 2013 at 12:28 PM, Kumar amit mehta wrote: > grep for copy_from_user_overflow gives me this: > > amit@ubuntu:~/linux-next/linux-next$ grep -ri copy_from_user_overflow * > arch/s390/include/asm/uaccess.h:extern void copy_from_user_overflow(void) > arch/s390/include/asm/uaccess.h:copy_from_user_overflow(); > arch/tile/include/asm/uaccess.h:extern void copy_from_user_overflow(void) > arch/tile/include/asm/uaccess.h:copy_from_user_overflow(); > arch/parisc/include/asm/uaccess.h:extern void copy_from_user_overflow(void) > arch/parisc/include/asm/uaccess.h:copy_from_user_overflow(); > arch/x86/include/asm/uaccess_32.h:extern void copy_from_user_overflow(void) > arch/x86/include/asm/uaccess_32.h: copy_from_user_overflow(); > drivers/vfio/pci/vfio_pci_config.c: * with count of 1/2/4 and hits > copy_from_user_overflow without this. > lib/usercopy.c:void copy_from_user_overflow(void) IMHO, I think uaccess_32.h is what you need here. I draw that conclusion after checking this line: http://lxr.linux.no/#linux+v3.8.3/arch/x86/include/asm/uaccess_32.h#L194 I might be wrong, so feel free to test first -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel warning messages- protocol 0000 is buggy, dev eth0
Sengottuvelan S writes: > Hi > > I am getting kernel messages = "protocol is buggy, dev eth0" in my > kernel while calling dev_queue_xmit(skb);. The packet is successfully > tranmitted on the wire but these messages are keep coming on the console. > > I am not sure what is the exact modification needed to avoid these kernel > messages. Can you someone help on this. > > Exact code I have in my driver code: > tx_len is length of the packet to be transmitted > tx_packet is the pointer to packet container. > > >skb = dev_alloc_skb(tx_len); > if (skb == NULL) > return -1; >skb_put(skb,tx_len); > >memcpy(skb->data, tx_packet, tx_len); > >skb->dev = dev_my_device; > >skb->len = tx_len; > > dev_queue_xmit(skb); > dev_put ( dev_my_device); > return 0; You didn't set skb->network_header. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
only for test
FYI___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
