Major/minor numbers
Pranay Kumar Srivastava
Pranay.Shrivastava at hcl.com
Wed Mar 6 01:38:11 EST 2013
> -----Original Message-----
> From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
> bounces at kernelnewbies.org] On Behalf Of kernelnewbies-
> request at kernelnewbies.org
> Sent: Tuesday, March 05, 2013 5:53 PM
> To: kernelnewbies at kernelnewbies.org
> Subject: Kernelnewbies Digest, Vol 28, Issue 9
>
> Send Kernelnewbies mailing list submissions to
> kernelnewbies at kernelnewbies.org
>
> 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
> kernelnewbies-request at kernelnewbies.org
>
> You can reach the person managing the list at
> kernelnewbies-owner at kernelnewbies.org
>
> 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 (Valdis.Kletnieks at vt.edu)
> 4. pthread_lock (ishare)
> 5. Re: pthread_lock (Mandeep Sandhu)
> 6. Re: pthread_lock (Valdis.Kletnieks at vt.edu)
> 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 <pulsarpietro at aol.com>
> Subject: Module compilation error
> To: kernelnewbies at kernelnewbies.org
> Message-ID: <8CFE7524C1296F0-1764-9EDF at 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
> pulsarpietro at aol.com
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 Mar 2013 09:07:51 +0700
> From: Mulyadi Santosa <mulyadi.santosa at gmail.com>
> Subject: Re: Module compilation error
> To: Pietro Paolini <pulsarpietro at aol.com>
> Cc: kernelnewbies at kernelnewbies.org
> Message-ID:
> <CAGdaadZ=eziBhY6zTFzSC5PZ_yTzgnVjQ0rgbk_SQQCjyt6ZBA at mail.
> gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Mar 5, 2013 at 7:48 AM, Pietro Paolini <pulsarpietro at aol.com>
> 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: Valdis.Kletnieks at vt.edu
> Subject: Re: Module compilation error
> To: Mulyadi Santosa <mulyadi.santosa at gmail.com>
> Cc: Pietro Paolini <pulsarpietro at aol.com>,
> kernelnewbies at kernelnewbies.org
> Message-ID: <6607.1362451666 at turing-police.cc.vt.edu>
> 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 <pulsarpietro at aol.com>
> 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 <june.tune.sea at gmail.com>
> Subject: pthread_lock
> To: kernelnewbies at kernelnewbies.org
> Message-ID: <20130305044402.GA3117 at debian.localdomain>
> 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 <mandeepsandhu.chd at gmail.com>
> Subject: Re: pthread_lock
> To: ishare <june.tune.sea at gmail.com>
> Cc: kernelnewbies <kernelnewbies at kernelnewbies.org>
> Message-ID:
> <CAC+QLdSaL0cc+uNmYSrvRCbh9tZfirqS0dTcYbC_V0PDejRMYw at ma
> il.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Mar 5, 2013 at 10:14 AM, ishare <june.tune.sea at gmail.com> 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
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 05 Mar 2013 01:02:51 -0500
> From: Valdis.Kletnieks at vt.edu
> Subject: Re: pthread_lock
> To: Mandeep Sandhu <mandeepsandhu.chd at gmail.com>
> Cc: kernelnewbies <kernelnewbies at kernelnewbies.org>, ishare
> <june.tune.sea at gmail.com>
> Message-ID: <21589.1362463371 at turing-police.cc.vt.edu>
> 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 <sh2008ka at gmail.com>
> Subject: Major/minor numbers
> To: kernelnewbies <kernelnewbies at kernelnewbies.org>
> Message-ID: <1362465123.7863.6.camel at oc5268484881.ibm.com>
> 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 <mandeepsandhu.chd at gmail.com>
> Subject: Re: pthread_lock
> To: Valdis.Kletnieks at vt.edu
> Cc: kernelnewbies <kernelnewbies at kernelnewbies.org>, ishare
> <june.tune.sea at gmail.com>
> Message-ID:
> <CAC+QLdSm48VSoUTqQWuBsQ5Sg_3y6VFT=zM-
> kma1PKvG_n4SdQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Mar 5, 2013 at 11:32 AM, <Valdis.Kletnieks at vt.edu> 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 <june.tune.sea at gmail.com>
> Subject: Re: pthread_lock
> To: kernelnewbies at kernelnewbies.org
> Message-ID: <20130305100546.GA2541 at debian.localdomain>
> 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, <Valdis.Kletnieks at vt.edu> 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 <chambilkethakur at gmail.com>
> Subject: Re: Major/minor numbers
> To: Shraddha Kamat <sh2008ka at gmail.com>
> Cc: kernelnewbies <kernelnewbies at kernelnewbies.org>
> Message-ID:
> <CAJnfX5uEbxk2kPLqtS3KsvH01C+iPrj3K3qdgunq9SbrD9GBnQ at mail.
> gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, Mar 5, 2013 at 6:32 AM, Shraddha Kamat <sh2008ka at gmail.com>
> 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
> > Kernelnewbies at kernelnewbies.org
> > 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
> Kernelnewbies at kernelnewbies.org
> 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.
----------------------------------------------------------------------------------------------------------------------------------------------------
More information about the Kernelnewbies
mailing list