All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mike \(mwester\)" <mwester@dls.net>
To: <openembedded-devel@lists.openembedded.org>
Subject: Need advice on changing kernel.bbclass
Date: Wed, 6 Jun 2007 23:30:31 -0500	[thread overview]
Message-ID: <03ec01c7a8bc$95a2f030$6e01a8c0@twilight> (raw)

Deep inside kernel.bbclass, do_split_packages() is invoked, and one of the
arguments passed in is:
   "extra_depends='update-modules kernel-%s'...".

I need to make that conditional, so that when DISTRO=="unslung", it becomes:
   "extra_depends='update-modules kernel-image-%s'...".

Why, you ask?  Well, for good or bad, there are numerous NSLU2's out there
that are expecting kernel modules to depend upon "kernel-image-2.4.22-xfs",
not on "kernel-2.4.22-xfs".  Since we can't reinstall those systems to make
them accomodate the change (something changed, perhaps along with bitbake
1.8?), the reasonable solution is to adjust the build process so that we
generate kernel module ipks with the same dependencies that they used to be
built with.  Kernel modules are build "on the fly" inside kernel.bbclass
with some python code; that python code is what is establishing the
dependencies, and that's the code that needs to be adjusted to handle this
situation.

Before I commit hideous hackery on kernel.bbclass, I thought perhaps I
should appeal to the community for some advice and feedback on how best to
do this.  I was thinking a conditional in the python code would be easiest,
and cleanest.  I don't know how to write such a conditional, but lack of
knowlege has never stopped me before ;-)  Python can't be that hard to
learn.

If there's a better, suggestion, I'm open for it.  The Unslung kernel is
frozen at 2.4.22-xfs (since that's what Linksys ships, and we need to remain
compatible with their kernel modules and software).  That sort of means that
spending a lot of work on an elegant solution for Unslung is pretty much a
waste of time -- quick and simple, so that we can go about building some new
kernel modules and getting them into the feeds (with correct dependencies),
is the goal.

For completeness, below is the entire original source line out of
kernel.bbclass:

   do_split_packages(d, root='/lib/modules', file_regex=module_regex,
output_pattern=module_pattern, description='%s kernel module',
postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata,
extra_depends='update-modules kernel-%s' % bb.data.getVar("KERNEL_VERSION",
d, 1))

Thanks!
Mike (mwester)





             reply	other threads:[~2007-06-07  4:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-07  4:30 Mike (mwester) [this message]
2007-06-07  6:39 ` Need advice on changing kernel.bbclass Marcin Juszkiewicz
2007-06-07 11:26   ` Mike (mwester)
2007-06-07 11:56   ` Mike (mwester)
2007-06-07 12:41     ` Marcin Juszkiewicz
2007-06-07 18:45     ` Richard Purdie
2007-06-07 20:51       ` Mike (mwester)

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='03ec01c7a8bc$95a2f030$6e01a8c0@twilight' \
    --to=mwester@dls.net \
    --cc=openembedded-devel@lists.openembedded.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.