RE: Major/minor numbers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx [mailto:kernelnewbies-
> bounces@xxxxxxxxxxxxxxxxx] On Behalf Of kernelnewbies-
> request@xxxxxxxxxxxxxxxxx
> Sent: Tuesday, March 05, 2013 5:53 PM
> To: kernelnewbies@xxxxxxxxxxxxxxxxx
> Subject: Kernelnewbies Digest, Vol 28, Issue 9
> 
> Send Kernelnewbies mailing list submissions to
> 	kernelnewbies@xxxxxxxxxxxxxxxxx
> 
> 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@xxxxxxxxxxxxxxxxx
> 
> You can reach the person managing the list at
> 	kernelnewbies-owner@xxxxxxxxxxxxxxxxx
> 
> 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@xxxxxx)
>    4. pthread_lock (ishare)
>    5. Re: pthread_lock (Mandeep Sandhu)
>    6. Re: pthread_lock (Valdis.Kletnieks@xxxxxx)
>    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@xxxxxxx>
> Subject: Module compilation error
> To: kernelnewbies@xxxxxxxxxxxxxxxxx
> 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
> pulsarpietro@xxxxxxx
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 5 Mar 2013 09:07:51 +0700
> From: Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>
> Subject: Re: Module compilation error
> To: Pietro Paolini <pulsarpietro@xxxxxxx>
> Cc: kernelnewbies@xxxxxxxxxxxxxxxxx
> 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 <pulsarpietro@xxxxxxx>
> 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@xxxxxx
> Subject: Re: Module compilation error
> To: Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>
> Cc: Pietro Paolini <pulsarpietro@xxxxxxx>,
> 	kernelnewbies@xxxxxxxxxxxxxxxxx
> Message-ID: <6607.1362451666@xxxxxxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxx>
> 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@xxxxxxxxx>
> Subject: pthread_lock
> To: kernelnewbies@xxxxxxxxxxxxxxxxx
> Message-ID: <20130305044402.GA3117@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@xxxxxxxxx>
> Subject: Re: pthread_lock
> To: ishare <june.tune.sea@xxxxxxxxx>
> Cc: kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
> 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 <june.tune.sea@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Tue, 05 Mar 2013 01:02:51 -0500
> From: Valdis.Kletnieks@xxxxxx
> Subject: Re: pthread_lock
> To: Mandeep Sandhu <mandeepsandhu.chd@xxxxxxxxx>
> Cc: kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>,	ishare
> 	<june.tune.sea@xxxxxxxxx>
> Message-ID: <21589.1362463371@xxxxxxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxx>
> Subject: Major/minor numbers
> To: kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
> Message-ID: <1362465123.7863.6.camel@xxxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxx>
> Subject: Re: pthread_lock
> To: Valdis.Kletnieks@xxxxxx
> Cc: kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>,	ishare
> 	<june.tune.sea@xxxxxxxxx>
> Message-ID:
> 	<CAC+QLdSm48VSoUTqQWuBsQ5Sg_3y6VFT=zM-
> kma1PKvG_n4SdQ@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Tue, Mar 5, 2013 at 11:32 AM,  <Valdis.Kletnieks@xxxxxx> 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@xxxxxxxxx>
> Subject: Re: pthread_lock
> To: kernelnewbies@xxxxxxxxxxxxxxxxx
> Message-ID: <20130305100546.GA2541@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@xxxxxx> 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@xxxxxxxxx>
> Subject: Re: Major/minor numbers
> To: Shraddha Kamat <sh2008ka@xxxxxxxxx>
> Cc: kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
> 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 <sh2008ka@xxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxx
> 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
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux