linux-kernel - Re: [PATCH 00/23] add register_chrdev_ids() to char

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 21 May 2011 14:14:23 -0700
From:	Greg KH <gregkh@...e.de>
To:	Jim Cromie <jim.cromie@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/23] add register_chrdev_ids() to char_dev.c, API

On Fri, May 20, 2011 at 11:15:04PM -0600, Jim Cromie wrote:
> On Thu, May 19, 2011 at 4:44 PM, Greg KH <gregkh@...e.de> wrote:
> > On Thu, May 19, 2011 at 03:33:03PM -0600, Jim Cromie wrote:
> >> over on kernelnewbies, gregkh said:
> >>
> >>      The chardev stuff is a mess, I keep meaning for years to clean it
> >>      up.  Any proposals on a sane interface for this stuff is greatly
> >>      appreciated.
> >>
> >> this is a 1st step.
> >>
> >> register_chrdev_ids() replaces and deprecates register_chrdev_region()
> >> and alloc_chrdev_region() with a single function that works for both
> >> dynamic and static major numbers.
> >>
> >> Like alloc_chrdev_region(), 1st arg is a dev_t*, but its an in/out
> >> parameter, and expects both major and minor to be preset, and thus the
> >> separate minor arg is dropped.  If major == 0, a dynamic major is
> >> reserved, saved into 1st arg, and thus available to caller afterwards.
> >>
> >> [PATCH 01/23] add register_chrdev_ids() to char_dev.c, API
> >> [PATCH 02/23] reimplement alloc_chrdev_region with
> >> [PATCH 03/23] use register_chrdev_ids to replace
> >> [PATCH 04/23] use register_chrdev_ids in drivers/tty/
> >> [PATCH 05/23] use register_chrdev_ids in drivers/infiniband/
> >> [PATCH 06/23] use register_chrdev_ids in drivers/media/
> >> [PATCH 07/23] use register_chrdev_ids in drivers/s390/
> >> [PATCH 08/23] use register_chrdev_ids in drivers/scsi/
> >> [PATCH 09/23] use register_chrdev_ids in drivers/staging/
> >>
> >> Ive held back the rest, no point in spamming.
> >
> > It's a nice first step, but that's the easy part, what is your 2nd
> > through 4th one going to be?  :)
> >
> > I'd also like to sanatize the function namespace a bit as well, how
> > about chrdev_register_ids() instead?
> 
> that seems sensible, modern.
> also have register_chrdev(), which I presume should also be fixed.
> 
> > Ideally, we could drop down to a single register/unregister pair of
> > functions, that are easy to use and understand.
> 
> __register_chrdev() does more stuff, mainly around cdevs, fops.
> If fops was passed as NULL, we just do the __register_chardev_region()
> and return early, skipping the cdev_alloc() and everything afterwards,
> thus yielding register_chrdev_ids() behavior.
> 
> > Do you think you can
> > get there with this intermediate step or do you want to step back and
> > rethink this?
> 
> hmm.  If above is right, theres no need for the new api fn I added,
> and probably should also drop the __ on both (un)?register_chardev.
> So thats step 2 :)  Any ideas for 3 ?

Well, what do you think the end result should look like?  That will
determine the steps needed here.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/