Re: fixing kobj signatures

On Fri, 29 May 2009 17:15:32 +0300
Andriy Gapon <avg@xxxxxxxxxxx> wrote:

I think I have completed fixing signatures of kobj method
implementations in the whole head tree.
The current diff here:
http://people.freebsd.org/~avg/

It is quite arbitrarily split into the following files:
kobj-agp.diff
kobj-arm.diff
kobj-linker.diff
kobj-other.diff
kobj-sound.diff

Most of the changes are quite trivial but not all.

o kobj-linker.diff - I am not sure if changing interface signature
was a good idea.

o kobj-sound.diff - this is a slightly updated version of the patch
previously posted to multimedia ml;
Ariff, could you please let me know about your plans with respect to
8.0 release?

I'm actually in the middle of discussion with joel@ to wrap things up
in order to get everything under my sleeves into tree before freeze
Your diff looks simmilar to what I intended to commit as a whole, so I
guess I'm ok with it.

Except that, let me deal with it within next week unless I'm wrong
about June 25th.

o kobj-arm.diff - it seems that npe_miibus_writereg in
sys/arm/xscale/ixp425/if_npe.c) could now make use of non-void
return type to properly report errors (XXX cases). But I am not sure
if it is actually checked in the calling code (otherwise how does it
work now?). Maybe there are more places like that.

Please review the patch. I might have done something wrong, made
some obvious mistake (like typo) or missed an opportunity to improve
the code beyond mechanical changes.

I tested the patch by enabling 'notyet' definition of KOBJMETHOD in
kobj.h and building the following: all arm kernels (without
modules), GENERIC kernels for all archs that have them (with
modules), LINT kernels for all archs that have them (without
modules).

It is quite possible, of course, that some incorrect signatures were
not found using the above build. For instance, in the code under
some non-default option. But I think the number of such functions
should be quite small and they should be trivial to fix later.

I propose this patch for inclusion into the three before 8.0 freeze
depending on response from Ariff.
if this patch is not committed before 8.0 freeze (whole or any
significant portion of the patch), then I'd like to request a branch
under users/ where I could integrate this patch for future merging.



--
Ariff Abdullah
FreeBSD

... Recording in stereo is obviously too advanced
and confusing for us idiot ***** users :P ........

... Going with the standard and orthodox
is the death of intellect ..............

Attachment: pgpT6mcrM6Dge.pgp
Description: PGP signature

Relevant Pages

  • Re: Fw: signed kernel modules?
    ... I did a module signing patch some years ago. ... > into the kernel source in order to be able to load their signed module. ... the module loader refuses to load signed modules that are not GPLed? ... Digital signatures are starting to become valid ...
    (Linux-Kernel)
  • Re: Fw: signed kernel modules?
    ... >> We might end up with hardware companies deploying binary only signed ... >> simply revert this patch anymore as others have suggested. ... Digital signatures are starting to become valid ... What if distributions ship with this check removed (maybe distributions that ...
    (Linux-Kernel)
  • fixing kobj signatures
    ... I think I have completed fixing signatures of kobj method implementations in the ... Please review the patch. ... all arm kernels, ... I propose this patch for inclusion into the three before 8.0 freeze depending on ...
    (freebsd-current)
  • Re: FreeBSD Security Advisory FreeBSD-SA-02:13.openssh
    ... > The patch, advisory, and signatures were placed on ftp-master less ... Meanwhile, as always, the patch is readily available via CVSweb: ...
    (FreeBSD-Security)
  • Success! was Re: tvtime audio vs pcHDTV-3000 card and pvHDTV-1.6 software
    ... On Wednesday 16 March 2005 20:15, Gene Heskett wrote: ... > that a diff actually outputs only the src code differences, ... nor in that simple little 10 line patch that ... >Unforch, the 2.6.11 plain tree has not, in this case been built yet ...
    (Linux-Kernel)