Re: Recommendation for activating a deferred module init in the kernel

2008-06-17 Thread Jim Freeman 
On Tue, Jun 17, 2008 at 09:07:51PM +0200, J??rn Engel wrote:
 On Tue, 17 June 2008 11:23:18 -0700, Tim Bird wrote:
  
  I'm not that happy using an ioctl for this trigger.  What is
  the preferred method of activating a kernel feature like this?
  I presume something in /proc or /sys, but I'm not sure.
 
 I personally would be unhappy with any kind of interface for this.  It
 would be much nicer to make it transparent and still get the benefits.
 One option would be to start a kernel thread for the initialization and
 renice it to 19 or so.
 
 If you want an explicit trigger, you could either hook into init_post()
 or have hooks in the open functions of drivers with deferred
 initialization.  Obviously you need to wait for completion here anyway,
 so adding a trigger wouldn't be too expensive.

Run modprobe?  Have it do just the _init bits without a load/link
of the actual module text?


 J??rn
 
 -- 
 Joern's library part 13:
 http://www.chip-architect.com/
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list

2008-06-12 Thread Jim Freeman 
On Thu, Jun 12, 2008 at 05:46:42PM -0400, Mike Frysinger wrote:
 On Thu, Jun 12, 2008 at 5:42 PM, James Chapman wrote:
  David VomLehn wrote:
  Amen, brother. I'm fortunate in that I work for an organization that is
  quite good about enforcing code reviews, specifically, the QA organization
  is empowered to reject changes that do not have code review notes. I also
  have a fairly broad scope, so I'm in on code reviews for a number of open
  source components. At each such review, one of my criteria is whether the
  change is suitable for pushing back to the appropriate community. This is
  not necessarily a short-term way to make friends, but the long-term effects
  will be good both for the company and for the open source community in
  general.
 
  Now, if we can only get the time to actually push all the backlogged fixes
  out...
 
  Er, is that GPL or LGPL code that you're modifying? If so, you *have* to
  push those code changes out (make them available to others), whether you
  think people will be interested or not!
 
 umm, not really.  only if (1) he gives a binary to someone and (2)
 they ask him for the source.  if he doesnt distribute or no one asks,
 he doesnt have to do squat.
 -mike

And I'm just betting that when he said push ... fixes ... out
he meant work to get them incorporated back upstream, not just
make them available to requesters.

Most vendors these days have finally gotten the clue that sources/changes
have to be made available to downstream requesters, but far fewer
are sufficiently self-enlightened to figure out that changes need to
be accepted upstream for them to keep flowing back.  And to make that
happen, vendors have to take on substantially higher overhead to win
acceptance of patches/changes upstream, an undertaking often sadly
fraught with hassle, uncertainty, and even peril.  So they mostly
don't bother.  To their (and their customers, and our) long-term
detriment.

And Cisco has probably learned by now (and by sad experience) to do
the Right (tm) thing.

...jfree
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html