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:	Wed, 9 Apr 2008 20:11:06 +0200
From:	Oliver Endriss <o.endriss@....de>
To:	v4l-dvb-maintainer@...uxtv.org
Cc:	"Michael Krufky" <mkrufky@...uxtv.org>, harvey.harrison@...il.com,
	akpm@...ux-foundation.org, mchehab@...radead.org,
	abraham.manu@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [v4l-dvb-maintainer] [PATCH] media: replace remaining __FUNCT ION__ occurences

Michael Krufky wrote:
> On Fri, Apr 4, 2008 at 11:09 AM, Michael Krufky <mkrufky@...uxtv.org> wrote:
> > On Thu, Apr 3, 2008 at 3:58 PM,  <mkrufky@...uxtv.org> wrote:
> >  >  Harvey,
> >  >
> >  >  If you decide to move forward with these cleanups now, please keep the
> >  >  previous discussion in mind -- please generate the changesets against
> >  >  the v4l-dvb master repository, hosted on linuxtv.org, and please
> >  >  separate the changesets by each level of the directory tree hierarchy.
> >
> >  Harvey,
> >
> >  You sent in three patches, video/ , common/ , and dvb/ ... but these
> >  patches are way too large.
> >
> >  Please break these down by each level of the directory tree hierarchy,
> >  like I asked previously.
> >
> >  Make one patch for files inside media/video/*.[ch]
> >  make one patch for files inside media/video/cx88/*.[ch]
> >  make one patch for files inside media/video/saa7134/*.[ch]
> >  [...]
> >  make one patch for files inside media/dvb/b2c2/*.[ch]
> >  make one patch for files inside media/dvb/frontends/*.[ch]
> >  [...]
> >  etc.
> 
> Harvey,
> 
> I have received your entire patchset.  Some patches have already been
> merged into our development tree, others have been dropped, since some
> of individual driver maintainers have decided to remove the
> __FUNCTION__ macro from their source code altogether, rather than
> accept this change.
> 
> I have merged the remaining pending patches into a mercurial tree,
> hosted on linuxtv.org:
> 
> http://linuxtv.org/hg/~mkrufky/function-func
> 
> Please note that I had to manually apply patches 8, 11 and 13, since
> you generated your changes against the git repository rather than the
> official v4l-dvb development repository hosted on linuxtv.org.
> 
> I must stress this -- all v4l-dvb patches, ESPECIALLY
> codingstyle-cleanups (due to the nature of those patches, touching
> many many files at once), should always be generated against the
> v4l-dvb master development repository hosted on linuxtv.org.
> 
> Now, I have a question.....
> 
> About this change from __FUNCTION__ to __func__ , I understand that
> this change is being done kernel-wide.  At first, I had blindly
> accepted this change as a kernel-janitor "cleanup", until it was
> pointed out to me last night, that older compilers do not support
> __func__.  Sure, one can always do the following for compat:
> 
> #ifndef __func__
>  #define __func__ __FUNCTION__
> #endif /* __func__ */
> 
> ...but the question is raised, why are we making this change in the first place?
> 
> Don't get me wrong -- as I said before, I understand that this change
> is kernel-wide, and I am not arguing against it.  I will continue on
> to have this merged into 2.6.26.  I would just like to see a link that
> points to a discussion thread on LKML that explains the reasons for
> this change, and where this change was globally agreed to.  Again -- I
> am not challenging these patches.  I merely want to read more
> information as to why we are making this move.
> 
> In the meanwhile, below is the checkpatch.pl fallout after applying
> your __FUNCTION__ to __func__ series.  Since you are working on these
> codingstyle cleanups anyway, I'd imagine that you won't mind fixing
> these checkpatch.pl "errors" and "warnings" before we merge these
> changes.
> 
> I understand if you don't want to alter code that you may not be
> directly involved in, but I am sure you will have no trouble at least
> fixing the "comma after space" and "line over 80 characters" cases.
> 
> Please generate the additional cleanups against the mercurial tree
> that I merged your previous series to:
> 
> http://linuxtv.org/hg/~mkrufky/function-func
> 
> Also, please generate the codingstyle cleanup patches individually
> based on the directory structure, just as you did in your last series.
> 
> See below for the checkpatch.pl "errors" and "warnings".
> 
> Regards,
> 
> Mike

I suggest to _ignore_ the line-length warnings.
Fixing them makes the code less readable than the original code in most
cases...

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ