Add defines to track the minor numbers for each SGX device in
preparation for moving the helper code and provisioning device to the
common subsystem, and in preparation for adding a third device, i.e. a
virtual EPC device.
Signed-off-by: Sean Christopherson
---
arch/x86/kernel/cpu/sgx/driver
s. It loaded but fell back
> >to unconfigured mode.
> >
> >comedi_test comedi_testd: ran out of minor numbers for board device files
> >comedi_test comedi_testd: driver 'comedi_test' could not create device.
> >comedi_test: unable to auto-configure device
> >
>
; >>
> >>Don't set comedi_num_legacy_minors=48, then?
> >>
> >>This doesn't seem like the right fix at all. Why only allow one auto
> >>configured board? Why not 5 or 10?
> >>
> >
> >Let me explain, the original intended b
this case, a default to auto-configure comedi_test module failed
to auto-configure with the following messages. It loaded but fell back
to unconfigured mode.
comedi_test comedi_testd: ran out of minor numbers for board device files
comedi_test comedi_testd: driver 'comedi_test' could no
s to allow user to
reserve up to 48 minor numbers for legacy devices.
Therefore [sudo modprobe comedi comedi_num_legacy_minors=3]
will allocate minor number 0, 1, 2 for legacy devices.
Subsequent loading of an auto-configured device will use minor number 3.
And the next one number 4 so on and so f
ed behaviour is to allow user to
reserve up to 48 minor numbers for legacy devices.
Therefore [sudo modprobe comedi comedi_num_legacy_minors=3]
will allocate minor number 0, 1, 2 for legacy devices.
Subsequent loading of an auto-configured device will use minor number 3.
And the next one number
On Sun, Mar 05, 2017 at 03:22:33AM +0800, Cheah Kok Cheong wrote:
> If comedi module is loaded with the following max allowed parameter
> [comedi_num_legacy_minors=48], subsequent loading of an auto-configured
> device will fail.
Don't set comedi_num_legacy_minors=48, then?
This doesn't seem like
_test module failed
to auto-configure with the following messages. It loaded but fell back
to unconfigured mode.
comedi_test comedi_testd: ran out of minor numbers for board device files
comedi_test comedi_testd: driver 'comedi_test' could not create device.
comedi_test: unable to auto-c
out of minor numbers for board device files
comedi_test comedi_testd: driver 'comedi_test' could not create device.
comedi_test: unable to auto-configure device
This is due to changes in commit 38b9722a4414
("staging: comedi: avoid releasing legacy minors automatically") which
back in the late 1990's, and it was the cause of Much
> Hilarity (except on the part of the programmers who had to figure out
> why certain programs were stuck looping forever while trying to
> analyze a long AFS pathname...)
Yes, in fact, I do respect the unicity of the st_dev field, s
On Tue, Apr 15, 2014 at 05:32:41PM +0200, Emmanuel Colbus wrote:
> > In addition the
> > standards and common sense together pretty much imply that you need each
> > device to at least have a unique identifier.
> >
>
> Why is it? I mean, as far as userspace is concerned, they do have a
> unique id
Le 15/04/2014 17:02, Austin S Hemmelgarn a écrit :
> On 2014-04-15 09:42, Emmanuel Colbus wrote:
>> Now, back to the filesystem...
>>
>> In order to associate devices to their files, the Linux kernel uses
>> their major and minor numbers. However, mine doesn't; inst
> Why is it? I mean, as far as userspace is concerned, they do have a
> unique identifier : their name. How would it be problematic that the
No - a name is never a unique identifier in a Unix system. The
fundamental object is the file handle. If I want to be able to answer the
question
"are these
Le 15/04/2014 17:06, One Thousand Gnomes a écrit :
>> In order to associate devices to their files, the Linux kernel uses
>> their major and minor numbers. However, mine doesn't; instead, I've
>> attributed myself a single group of values (major=0, minor=0, for both
> In order to associate devices to their files, the Linux kernel uses
> their major and minor numbers. However, mine doesn't; instead, I've
> attributed myself a single group of values (major=0, minor=0, for both
> character-mode and block-mode special files), with the meanin
On 2014-04-15 09:42, Emmanuel Colbus wrote:
> Now, back to the filesystem...
>
> In order to associate devices to their files, the Linux kernel uses
> their major and minor numbers. However, mine doesn't; instead, I've
> attributed myself a single group of values (m
Now, back to the filesystem...
In order to associate devices to their files, the Linux kernel uses
their major and minor numbers. However, mine doesn't; instead, I've
attributed myself a single group of values (major=0, minor=0, for both
character-mode and block-mode special files)
On Fri, Dec 27, 2013 at 10:44:24AM -0800, Greg KH wrote:
> Please get approval for this patch from others within Linaro before
> sending it out again. Linaro has a process in place for this type of
> thing, please use it, otherwise it makes people like me really grumpy
> and upset and causes me t
On Fri, Dec 27, 2013 at 03:47:31PM +0530, Tushar Behera wrote:
> On 27 December 2013 12:08, Greg KH wrote:
> > On Fri, Dec 27, 2013 at 12:00:20PM +0530, Tushar Behera wrote:
> >> On 27 December 2013 10:48, Greg KH wrote:
> >> > On Fri, Dec 27, 2013 at 10:37:28AM +0530, Tushar Behera wrote:
>
> [
On 27 December 2013 12:08, Greg KH wrote:
> On Fri, Dec 27, 2013 at 12:00:20PM +0530, Tushar Behera wrote:
>> On 27 December 2013 10:48, Greg KH wrote:
>> > On Fri, Dec 27, 2013 at 10:37:28AM +0530, Tushar Behera wrote:
[ ... ]
>> >> @@ -951,8 +949,6 @@ static struct uart_driver s3c24xx_uart_dr
On Fri, Dec 27, 2013 at 10:43:23AM +0400, Alexander Shiyan wrote:
> Hello.
> > On Fri, Dec 27, 2013 at 12:00:20PM +0530, Tushar Behera wrote:
> > > On 27 December 2013 10:48, Greg KH wrote:
> > > > On Fri, Dec 27, 2013 at 10:37:28AM +0530, Tushar Behera wrote:
> > > >> The hard-coded values clash
Hello.
> On Fri, Dec 27, 2013 at 12:00:20PM +0530, Tushar Behera wrote:
> > On 27 December 2013 10:48, Greg KH wrote:
> > > On Fri, Dec 27, 2013 at 10:37:28AM +0530, Tushar Behera wrote:
> > >> The hard-coded values clash with the values set for amba-pl011 serial
> > >> driver. Because of this the
On Fri, Dec 27, 2013 at 12:00:20PM +0530, Tushar Behera wrote:
> On 27 December 2013 10:48, Greg KH wrote:
> > On Fri, Dec 27, 2013 at 10:37:28AM +0530, Tushar Behera wrote:
> >> The hard-coded values clash with the values set for amba-pl011 serial
> >> driver. Because of this there is no serial o
On 27 December 2013 10:48, Greg KH wrote:
> On Fri, Dec 27, 2013 at 10:37:28AM +0530, Tushar Behera wrote:
>> The hard-coded values clash with the values set for amba-pl011 serial
>> driver. Because of this there is no serial output on Samsung boards
>> if amba-pl011 is enabled alongwith samsung-s
On Fri, Dec 27, 2013 at 10:37:28AM +0530, Tushar Behera wrote:
> The hard-coded values clash with the values set for amba-pl011 serial
> driver. Because of this there is no serial output on Samsung boards
> if amba-pl011 is enabled alongwith samsung-serial driver.
>
> Remove the hardcoded values a
The hard-coded values clash with the values set for amba-pl011 serial
driver. Because of this there is no serial output on Samsung boards
if amba-pl011 is enabled alongwith samsung-serial driver.
Remove the hardcoded values and let the framework decide on
appropriate major/minor number. This is re
On Oct 2, 2012, at 5:12 PM, Andrew Morton wrote:
...
>> +static int
>> +minor_get(ulong *minor)
>> {
>> -struct aoedev *d;
>> ulong flags;
>> +ulong n;
>> +int error = 0;
>> +
>> +spin_lock_irqsave(&used_minors_lock, flags);
>> +n = find_first_zero_bit(used_minors, N_DEVS);
On Oct 2, 2012, at 5:17 PM, Andrew Morton wrote:
...
>> The static arrangement is still available with aoe_dyndevs=0, and
>> the aoe-stat tool from the userland aoetools package, the user
>> space counterpart to the aoe driver, recognizes the case where
>> there is a mismatch between the minor num
limitations too confining.
>
> These changes make the dynamic block device minor numbers the
> default, removing the limitations on usable AoE addresses.
>
> The static arrangement is still available with aoe_dyndevs=0, and
> the aoe-stat tool from the userland aoetools package, t
minor number, the block device minor numbers are now
> allocated on demand.
>
> ...
Very minor things...
>
> ...
>
> +static int
> +minor_get(ulong *minor)
> {
> - struct aoedev *d;
> ulong flags;
> + ulong n;
> + int error =
d slot address space is often used sparsely.
> Instead of using a static mapping between AoE addresses and the
> block device minor number, the block device minor numbers are now
> allocated on demand.
>
> Signed-off-by: Ed Cashin
> ---
> drivers/block/aoe/aoe.h|6 ++--
minor numbers the
default, removing the limitations on usable AoE addresses.
The static arrangement is still available with aoe_dyndevs=0, and
the aoe-stat tool from the userland aoetools package, the user
space counterpart to the aoe driver, recognizes the case where
there is a mismatch between the
users commonly
use slot numbers much greater than that.
The AoE shelf and slot address space is often used sparsely.
Instead of using a static mapping between AoE addresses and the
block device minor number, the block device minor numbers are now
allocated on demand.
Signed-off-by: Ed Cashin
Hi Dmitry
On Fri, Sep 21, 2012 at 10:07 AM, Dmitry Torokhov
wrote:
[snip] See my previous review
> diff --git a/drivers/input/joydev.c b/drivers/input/joydev.c
> index f0909ed..c82f76f 100644
> --- a/drivers/input/joydev.c
> +++ b/drivers/input/joydev.c
> @@ -27,6 +27,7 @@
> #include
> #incl
Hi Dmitry
On Fri, Sep 21, 2012 at 10:51 PM, Dmitry Torokhov
wrote:
> On Friday, September 21, 2012 09:18:00 PM David Herrmann wrote:
>> Hi Dmitry
>>
>> On Fri, Sep 21, 2012 at 11:22 AM, David Herrmann
>>
>> wrote:
>> > Hi Dmitry
>> >
>> > On Fri, Sep 21, 2012 at 10:07 AM, Dmitry Torokhov
>> >
>>
On Friday, September 21, 2012 09:18:00 PM David Herrmann wrote:
> Hi Dmitry
>
> On Fri, Sep 21, 2012 at 11:22 AM, David Herrmann
>
> wrote:
> > Hi Dmitry
> >
> > On Fri, Sep 21, 2012 at 10:07 AM, Dmitry Torokhov
> >
> > wrote:
> >> Thank you very much for working on this, unfortunately your p
Hi Dmitry
On Fri, Sep 21, 2012 at 10:07 AM, Dmitry Torokhov
wrote:
> Thank you very much for working on this, unfortunately your patch extends the
> existing infrastructure handling of character devices in input core,
> which is quite rigid and sub-optimal.
>
> For a while now I wanted to stop in
Hi David,
On Thu, Sep 20, 2012 at 07:52:00PM +0200, David Herrmann wrote:
> Hi
>
> This is version 2 of the Dynamic Minor Numbers support for input devices.
> Version 1 can be found here:
> http://thread.gmane.org/gmane.linux.kernel.input/26842
>
> For historical reason
Hi
This is version 2 of the Dynamic Minor Numbers support for input devices.
Version 1 can be found here:
http://thread.gmane.org/gmane.linux.kernel.input/26842
For historical reasons, each input-handler (like evdev, joydev etc.) gets 32
minor numbers assigned statically. That means, if we
On Fri, Aug 03, 2007 at 05:13:51PM -0400, Chris Snook wrote:
> You're correct that dynamic major/minor numbers are sufficient for most
> purposes, but embedded users really need their static numbers. As for
> ripping out major/minor numberings, that's a non-starter. Too mu
fs to create the required entries
in /dev. udev doesn't care about major/minor numbers.
3) Most distros already use udev and maybe initramfs. If there are
exceptions, they can be easily converted.
For the first part, I'm asking: is there any reason why new char/block
drivers shouldn'
/dev. udev doesn't care about major/minor numbers.
3) Most distros already use udev and maybe initramfs. If there are
exceptions, they can be easily converted.
For the first part, I'm asking: is there any reason why new char/block
drivers shouldn't use dynamic major/minor numbers?
> Im very interested in 32bit dev_t or at least implementing
> the 'lots of majors' half of it because we are probably
> going to need it in the 2.5 years before we have a 2.6
Yes, a larger dev_t has been desirable for a long time,
and more and more kludges are invented to work around its lack.
S
> Hmm. You make me search for this old patch.
> Since Linus' reaction was not exactly positive I left
> the topic again, but there must be a copy somewhere..
Given current real world evolution Im very interested in 32bit dev_t or at
least implementing the 'lots of majors' half of it because we ar
>> The exercise is essentially the patch that I sent last month or so.
> mknod takes a 32bit input
> the stat64 padding only has room for 32bits
Hmm. You make me search for this old patch.
Since Linus' reaction was not exactly positive I left
the topic again, but there must be a copy somewhere..
On Mon, May 14, 2001 at 03:57:21PM +0100, Alan Cox wrote:
> > > 20:12 is more common
> >
> > Which is major, which is minor?
>
> 20bit major
Well, AIX 4.3 (and 4.[12] I think as well) uses 16:16, and they
are preparing for 32:32 when the kernel finaly goes fully 64-bit. I
don't know en
> The fs and stat structs are set up to allow 32bits.
> 64bits is a major exercise
No. Inside the kernel the dev_t type does not really occur.
The exercise is essentially the patch that I sent last month or so.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> No. Inside the kernel the dev_t type does not really occur.
> The exercise is essentially the patch that I sent last month or so.
mknod takes a 32bit input
the stat64 padding only has room for 32bits
The kernel representation internally I dont care about, its probably a pointer
not a 32:32 tho
> That is not more common. Around us we see major:minor splits
> 8:24, 12:20, 14:18. If we want to use NFSv3 and communicate
> with all these systems we would do wise to use 32:32.
My error. 32:32 is however not interesting. The fs and stat structs
are set up to allow 32bits. 64bits is a major ex
>>> 20:12 is more common
>> Which is major, which is minor?
> 20bit major
That is not more common. Around us we see major:minor splits
8:24, 12:20, 14:18. If we want to use NFSv3 and communicate
with all these systems we would do wise to use 32:32.
[Reminds me of a discussion that ended unfini
Followup to: <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > > 20:12 is more common
> >
> > Which is major, which is minor?
>
> 20bit major
>
Surely you're jesting?
12 bit major, 20 bit minor is the only logical split. The need for
minors
> > 20:12 is more common
>
> Which is major, which is minor?
20bit major
> I have one (private) driver that requires around 5000 minors.
> (currently through some 20 majors) (Currently only just over half of
> these are physically installed)
Just use several. The split is a bit vague in mo
Alan Cox wrote:
> > 255. Has this limitation been some how addressed with 2.4? 256 devices
> > per module, sometimes is not enough, especially if you are in the SAN
> > environment; or when the 256 minors numbers are broken down to several
>
> 2.4 is using 16bit dev_t in kernel still. Applicati
> 255. Has this limitation been some how addressed with 2.4? 256 devices
> per module, sometimes is not enough, especially if you are in the SAN
> environment; or when the 256 minors numbers are broken down to several
2.4 is using 16bit dev_t in kernel still. Application space sees a much
large
To the best of my knowledge, dev_t number is still 16 bits with 8 most
significant bits being the major number and the other 8 bits being the
minor number; which of course means that minor numbers can only go up to
255. Has this limitation been some how addressed with 2.4? 256 devices
per
55 matches
Mail list logo
