From: Jiri Slaby <jirislaby@gmail.com>
To: Rolf Eike Beer <eike-kernel@sf-tec.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
rth@twiddle.net, dhowells@redhat.com, kumar.gala@freescale.com,
davem@davemloft.net, mhw@wittsend.com, support@comtrol.com,
Rogier Wolff <R.E.Wolff@bitwizard.nl>,
nils@kernelconcepts.de, cjtsai@ali.com.tw,
Lionel.Bouton@inet6.fr, benh@kernel.crashing.org,
mchehab@brturbo.com.br, laredo@gnu.org,
rbultje@ronald.bitfreak.net, middelin@polyware.nl, philb@gnu.org,
tim@cyberelk.net, campbell@torque.net, andrea@suse.de,
linux@advansys.com, chirag.kantharia@hp.com, mulix@mulix.org
Subject: Re: [PATCH] pci_find_device --> pci_get_device
Date: Tue, 19 Jul 2005 17:44:15 +0200 [thread overview]
Message-ID: <42DD1FCF.4050304@gmail.com> (raw)
In-Reply-To: <200507191327.44415@bilbo.math.uni-mannheim.de>
Rolf Eike Beer napsal(a):
>Jiri Slaby wrote:
>
>
>>Kernel version: 2.6.13-rc3-git4
>>
>>* This patch removes from kernel tree pci_find_device and changes
>>it with pci_get_device. Next, it adds pci_dev_put, to decrease reference
>>count of the variable.
>>* Next, there are some (about 10 or so) gcc warning problems (i. e.
>>variable may be unitialized) solutions, which were around code with old
>>pci_find_device.
>>
>>
>
>Is this the reason why you initialize members of static structs? If this is
>uninitialized it will end in the bss section and will be zeroed before the
>kernel uses is. If you do it will go into data section and add more bloat to
>the binary. At least this is the explanation I got once why not to do this.
>
>
I can't find now changes of initialization static variables, but i have
deleted section
dealing up with gcc warning from patch, it would go on a queue later.
>Many of the callers of pci_find_device() look like they are not ported to the
>2.6 driver API and do the scanning for devices themself. I think it would be
>a good idea to try to convert them to the new driver model instead of
>replacing this. When you mark this deprecated and they still use the old
>function everyone using this will see that there is some work to do.
>
>
I don't know now the difference between API accurately, but I'll study
it in a few days
and delete this sections from patch, alternatively rewrite the code.
>>* Some code was unpretty, or ugly, so the patch provides more readable
>>code, in some cases.
>>
>>
>
>If you try to beautify code then please use for_each_pci_dev() macro from
>include/linux/pci.h where possible.
>
>
Done.
>When you want something of this getting included you have to split that into
>pieces. Use extra patches for changes in coding style and functionality.
>
>
Yeah, the patch now provides only changes of pci_find problems.
[Gcc will be discussed later, after doing more changes and completing patch
against gcc 4, where are more warnings...]
OK. The new patch is:
http://www.fi.muni.cz/~xslaby/lnx/lnx-pci_find-2.6.13-r3g4_1.patch
and bzipped
http://www.fi.muni.cz/~xslaby/lnx/lnx-pci_find-2.6.13-r3g4_1.patch.bz2
[Kernel version is the same (2.6.13-rc3-git4)]
And the patch now contains only:
* This patch removes from kernel tree pci_find_device and changes
it with pci_get_device. Next, it adds pci_dev_put, to decrease reference
count of the variable.
* Some code was unpretty, or ugly, so the patch provides more readable
code, in some cases.
* Marks the function (pci_find_device) as deprecated in pci.h
--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~ jirislaby@gmail.com ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10
next prev parent reply other threads:[~2005-07-19 16:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-19 0:25 [PATCH] pci_find_device --> pci_get_device Jiri Slaby
2005-07-19 4:36 ` Rogier Wolff
2005-07-19 10:53 ` Jiri Slaby
2005-07-19 11:15 ` Rogier Wolff
2005-07-19 11:27 ` Rolf Eike Beer
2005-07-19 15:44 ` Jiri Slaby [this message]
2005-07-19 16:20 ` Rolf Eike Beer
2005-07-20 10:40 ` Jiri Slaby
2005-07-20 11:19 ` Rolf Eike Beer
2005-07-20 12:05 ` Jiri Slaby
2005-07-20 13:56 ` Rolf Eike Beer
2005-07-20 14:40 ` Jiri Slaby
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42DD1FCF.4050304@gmail.com \
--to=jirislaby@gmail.com \
--cc=Lionel.Bouton@inet6.fr \
--cc=R.E.Wolff@bitwizard.nl \
--cc=andrea@suse.de \
--cc=benh@kernel.crashing.org \
--cc=campbell@torque.net \
--cc=chirag.kantharia@hp.com \
--cc=cjtsai@ali.com.tw \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=eike-kernel@sf-tec.de \
--cc=kumar.gala@freescale.com \
--cc=laredo@gnu.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@advansys.com \
--cc=mchehab@brturbo.com.br \
--cc=mhw@wittsend.com \
--cc=middelin@polyware.nl \
--cc=mulix@mulix.org \
--cc=nils@kernelconcepts.de \
--cc=philb@gnu.org \
--cc=rbultje@ronald.bitfreak.net \
--cc=rth@twiddle.net \
--cc=support@comtrol.com \
--cc=tim@cyberelk.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox