On Mon, 2006-02-13 at 08:32 +0100, Arjan van de Ven wrote: > > I don't really like this. There's no benefit to using the 1394 major > > number. I'd rather see an improved alloc_chrdev_region() that does > > something like this but for the whole kernel (currently it "wastes" an > > entire major even if you only want 1 minor, and for what you're doing, > > grabbing 1 minor at a time makes the most sense.) > > why bother? There's a LOT of majors nowadays (12 bits) so... what's the > problem with keeping the kernel side simple? > (it's not as if userspace needs to care about the exact numbers anyway > for almost everything) Uh, ok. Seems pretty weird to effectively allocate 256 device numbers for just a single device, but ok :) I'll drop the patch and make it allocate a new major for every device plugged in. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: [RFC 2/4] firewire: dynamic cdev allocation below firewire major
- From: Arjan van de Ven <[email protected]>
- Re: [RFC 2/4] firewire: dynamic cdev allocation below firewire major
- From: Stefan Richter <[email protected]>
- Re: [RFC 2/4] firewire: dynamic cdev allocation below firewire major
- References:
- [RFC 0/4] firewire: interface to remote memory (mem1394)
- From: Johannes Berg <[email protected]>
- [RFC 2/4] firewire: dynamic cdev allocation below firewire major
- From: Johannes Berg <[email protected]>
- Re: [RFC 2/4] firewire: dynamic cdev allocation below firewire major
- From: Jody McIntyre <[email protected]>
- Re: [RFC 2/4] firewire: dynamic cdev allocation below firewire major
- From: Arjan van de Ven <[email protected]>
- [RFC 0/4] firewire: interface to remote memory (mem1394)
- Prev by Date: Re: Linux 2.6.16-rc3
- Next by Date: Re: CD writing in future Linux (stirring up a hornets' nest)
- Previous by thread: Re: [RFC 2/4] firewire: dynamic cdev allocation below firewire major
- Next by thread: Re: [RFC 2/4] firewire: dynamic cdev allocation below firewire major
- Index(es):