> -----Original Message-----
> From: [email protected] [mailto:kernelnewbies-
> [email protected]] On Behalf Of kernelnewbies-
> [email protected]
> Sent: Tuesday, March 05, 2013 5:53 PM
> To: [email protected]
> Subject: Kernelnewbies Digest, Vol 28, Issue 9
>
> Send Kernelnewbies mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific than "Re:
> Contents of Kernelnewbies digest..."
>
>
> Today's Topics:
>
> 1. Module compilation error (Pietro Paolini)
> 2. Re: Module compilation error (Mulyadi Santosa)
> 3. Re: Module compilation error ([email protected])
> 4. pthread_lock (ishare)
> 5. Re: pthread_lock (Mandeep Sandhu)
> 6. Re: pthread_lock ([email protected])
> 7. Major/minor numbers (Shraddha Kamat)
> 8. Re: pthread_lock (Mandeep Sandhu)
> 9. Re: pthread_lock (ishare)
> 10. Re: Major/minor numbers (Anuz Pratap Singh Tomar)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 4 Mar 2013 19:48:33 -0500 (EST)
> From: Pietro Paolini <[email protected]>
> Subject: Module compilation error
> To: [email protected]
> Message-ID: <8CFE7524C1296F0-1764-9EDF@webmail-
> m235.sysops.aol.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> Hi all,
>
> I tried, as beginner, to compile a simple module downloaded by internet,
> hello_printk, I am using ArchLinux and I followed the simplest way for
> compile a new kernel tree from here :
>
> https://wiki.archlinux.org/index.php/Kernels/Compilation/Arch_Build_Syste
> m
>
> But when I try to compile I catch these errors:
>
> echo >&2 " ERROR: Kernel configuration is invalid."; \
> echo >&2 " include/generated/autoconf.h or
> include/config/auto.conf are missing.";\
> echo >&2 " Run 'make oldconfig && make prepare' on kernel src
> to fix it."; \
> echo >&2 ; \
> /bin/false)
>
> Of course I checked the path of the kernel and under the directory wrote on
> the error messages I can find the files autoconf.h and auto.conf that I really
> don't understand what could be wrong, the makefile is really really simple
> then I can post it:
>
> obj-m := hello_printk.o
> KDIR ?= mypersonalpath/core/linux/src/linux-3.7
> PWD := $(shell pwd)
> default:
> $(MAKE) -C $(KDIR) M=$(PWD) modules
>
> Someone can help me ?
>
>
>
> Pietro Paolini
> [email protected]
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 Mar 2013 09:07:51 +0700
> From: Mulyadi Santosa <[email protected]>
> Subject: Re: Module compilation error
> To: Pietro Paolini <[email protected]>
> Cc: [email protected]
> Message-ID:
> <CAGdaadZ=eziBhY6zTFzSC5PZ_yTzgnVjQ0rgbk_SQQCjyt6ZBA@mail.
> gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Mar 5, 2013 at 7:48 AM, Pietro Paolini <[email protected]>
> wrote:
> > Hi all,
> >
> > I tried, as beginner, to compile a simple module downloaded by
> > internet, hello_printk, I am using ArchLinux and I followed the
> > simplest way for compile a new kernel tree from here :
> >
> > https://wiki.archlinux.org/index.php/Kernels/Compilation/Arch_Build_Sy
> > stem
> >
> > But when I try to compile I catch these errors:
> >
> > echo >&2 " ERROR: Kernel configuration is invalid."; \
> > echo >&2 " include/generated/autoconf.h or
> > include/config/auto.conf are missing.";\
> > echo >&2 " Run 'make oldconfig && make prepare' on kernel src
>
> try the suggested above step. IIRC, those commands will do things like
> preparing the neccessary object files, headers and so on, so it is ready for
> you to be used on your kernel programming.
>
> Apologize since I can't provide deeper details about this.
>
>
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 04 Mar 2013 21:47:46 -0500
> From: [email protected]
> Subject: Re: Module compilation error
> To: Mulyadi Santosa <[email protected]>
> Cc: Pietro Paolini <[email protected]>,
> [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> On Tue, 05 Mar 2013 09:07:51 +0700, Mulyadi Santosa said:
> > On Tue, Mar 5, 2013 at 7:48 AM, Pietro Paolini <[email protected]>
> wrote:
>
> > > echo >&2 " Run 'make oldconfig && make prepare' on kernel src
> >
> > try the suggested above step. IIRC, those commands will do things like
> > preparing the neccessary object files, headers and so on, so it is
> > ready for you to be used on your kernel programming.
>
> In addition, note that 'make oldconfig' followed by 'make prepare' will only
> do the right thing and result in a usable module if the source tree matches
> your running kernel. Doing 'make prepare' on a 3.7.2 source tree and then
> building a module against it will result in a module that loads in a 3.7.2
> kernel
> with the same .config - but a different .config and/or release will have
> anything from a module that simply won't load to one that blows up the
> system for mysterious reasons.
>
> It's *highly* recommended that you first learn how to build, install, and boot
> a self-compiled kernel (and remember to keep your distro kernel around),
> and then once you got that down, *then* start building external modules
> against it.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 865 bytes
> Desc: not available
> Url :
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130
> 304/e9b24b4a/attachment-0001.bin
>
> ------------------------------
>
> Message: 4
> Date: Tue, 5 Mar 2013 12:44:02 +0800
> From: ishare <[email protected]>
> Subject: pthread_lock
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> when pthread_unlock(mutex) is called , do other threads waiting for mutex
> be waked up immediately?
> or be waked up at the next schedule?
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 5 Mar 2013 11:02:45 +0530
> From: Mandeep Sandhu <[email protected]>
> Subject: Re: pthread_lock
> To: ishare <[email protected]>
> Cc: kernelnewbies <[email protected]>
> Message-ID:
> <CAC+QLdSaL0cc+uNmYSrvRCbh9tZfirqS0dTcYbC_V0PDejRMYw@ma
> il.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Mar 5, 2013 at 10:14 AM, ishare <[email protected]> wrote:
> >
> >
> > when pthread_unlock(mutex) is called , do other threads waiting for
> mutex be waked up immediately?
> > or be waked up at the next schedule?
>
> next schedule. I think the waiting threads (processes) will moved from the
> wait queue to the run queue from where they will be scheduled to run.
>
> HTH,
> -mandeep
>
> >
> >
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > [email protected]
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 05 Mar 2013 01:02:51 -0500
> From: [email protected]
> Subject: Re: pthread_lock
> To: Mandeep Sandhu <[email protected]>
> Cc: kernelnewbies <[email protected]>, ishare
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:
>
> > next schedule. I think the waiting threads (processes) will moved from
> > the wait queue to the run queue from where they will be scheduled to
> > run.
>
> For bonus points, read source code and/or comments and figure out what
> Linux does to prevent the 'thundering herd' problem (consider 100 threads
> all waiting on the same mutex - if you blindly wake all 100 up, you'll
> schedule
> them all, the first will find the mutex available and then re-take it, and
> then
> the next 99 will get run only to find it contended and go back to sleep. So
> figure out what Linux does in that case. :)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 865 bytes
> Desc: not available
> Url :
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130
> 305/9bdeb5af/attachment-0001.bin
>
> ------------------------------
>
> Message: 7
> Date: Tue, 05 Mar 2013 12:02:03 +0530
> From: Shraddha Kamat <[email protected]>
> Subject: Major/minor numbers
> To: kernelnewbies <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="UTF-8"
>
> Does the max number of devices supported by Linux limited by major minor
> number ? Can you please give me some pointers regarding this.
>
> -- Shraddha
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 5 Mar 2013 13:39:54 +0530
> From: Mandeep Sandhu <[email protected]>
> Subject: Re: pthread_lock
> To: [email protected]
> Cc: kernelnewbies <[email protected]>, ishare
> <[email protected]>
> Message-ID:
> <CAC+QLdSm48VSoUTqQWuBsQ5Sg_3y6VFT=zM-
> [email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Mar 5, 2013 at 11:32 AM, <[email protected]> wrote:
> > On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:
> >
> >> next schedule. I think the waiting threads (processes) will moved
> >> from the wait queue to the run queue from where they will be
> >> scheduled to run.
> >
> > For bonus points, read source code and/or comments and figure out what
> > Linux does to prevent the 'thundering herd' problem (consider 100
> > threads all waiting on the same mutex - if you blindly wake all 100
> > up, you'll schedule them all, the first will find the mutex available
> > and then re-take it, and then the next 99 will get run only to find it
> > contended and go back to sleep. So figure out what Linux does in that
> > case. :)
>
> Googling around, I found the 'thundering herd' being mentioned in relation
> to threads waiting on sockets using the accept() sys call.
> Are wait's on mutex's also plagued by the same issue? I guess it is, though
> what sys call would be used in this case?
>
> Thanks,
> -mandeep
>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 5 Mar 2013 18:05:46 +0800
> From: ishare <[email protected]>
> Subject: Re: pthread_lock
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Mar 05, 2013 at 01:39:54PM +0530, Mandeep Sandhu wrote:
> > On Tue, Mar 5, 2013 at 11:32 AM, <[email protected]> wrote:
> > > On Tue, 05 Mar 2013 11:02:45 +0530, Mandeep Sandhu said:
> > >
> > >> next schedule. I think the waiting threads (processes) will moved
> > >> from the wait queue to the run queue from where they will be
> > >> scheduled to run.
> > >
> > > For bonus points, read source code and/or comments and figure out
> > > what Linux does to prevent the 'thundering herd' problem (consider
> > > 100 threads all waiting on the same mutex - if you blindly wake all
> > > 100 up, you'll schedule them all, the first will find the mutex
> > > available and then re-take it, and then the next 99 will get run
> > > only to find it contended and go back to sleep. So figure out what
> > > Linux does in that case. :)
> >
> > Googling around, I found the 'thundering herd' being mentioned in
> > relation to threads waiting on sockets using the accept() sys call.
> > Are wait's on mutex's also plagued by the same issue? I guess it is,
> > though what sys call would be used in this case?
>
> the threads waiting on sockets will be waked up by net event.
> similarly,the waiters on mutex's can be wake up by signal.I guess it is
> pthread_cont_signal
>
>
> >
> > Thanks,
> > -mandeep
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 5 Mar 2013 12:21:47 +0000
> From: Anuz Pratap Singh Tomar <[email protected]>
> Subject: Re: Major/minor numbers
> To: Shraddha Kamat <[email protected]>
> Cc: kernelnewbies <[email protected]>
> Message-ID:
> <CAJnfX5uEbxk2kPLqtS3KsvH01C+iPrj3K3qdgunq9SbrD9GBnQ@mail.
> gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, Mar 5, 2013 at 6:32 AM, Shraddha Kamat <[email protected]>
> wrote:
>
> > Does the max number of devices supported by Linux limited by major
> > minor number ? Can you please give me some pointers regarding this.
> >
> http://stackoverflow.com/questions/14833467/maximum-values-of-major-
> and-minor-numbers-in-linux
[Pranay Kumar Srivastava] Just another point you should be careful when trying
to get device number from user land to kernel. I've got 2.6.32 SLES 11-SP1 and
the glibc provided major,minor and makedev functions are quite different from
what you'll encounter in kernel in form of macros. Apparently the userland
still uses 16 bit numbers on my SLES11-SP1 while internally kernel uses 32 bit
device numbers(split of 12bits,20bits). If you are thinking of passing direct
device numbers from user land to kernel refrain from it. Instead pass them
separately as major and minor numbers and then combine them using macros MKDEV
within kernel.
--P.K.S
> > -- Shraddha
> >
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > [email protected]
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>
>
>
> --
> Thank you
> Warm Regards
> Anuz
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130
> 305/47f643b5/attachment.html
>
> ------------------------------
>
> _______________________________________________
> Kernelnewbies mailing list
> [email protected]
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> End of Kernelnewbies Digest, Vol 28, Issue 9
> ********************************************
::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction,
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and
other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
Kernelnewbies mailing list
[email protected]
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
