[Yaird-devel] Bug#584565: Bug#584565: [PATCH] enable yaird for kernel.org 2.6.33.4

[Jonas Smedegaard]

On Thu, Jun 10, 2010 at 03:57:17PM +0200, Nils Radtke wrote:
>On Tue 2010-06-08 @ 02-01-54PM +0200, Jonas Smedegaard wrote:
># >A simple
># > touch /lib/modules/2.6.33.4/modules.{pci,usb}map
># >did work for me..
>#
># Hmm, interesting.  Perhaps then simply loosening up the code to skip
># parsing that file if unavailable is the way to go.  Need to
># investigate closer to ensure not loosing stabiliy or features by
># such approach.
>I'd say, it should work because it has to parse the /sys fs anyway (or
>does it shortcut when there's info available from the maps?
>If so, then loosening up is the way I'd go, as the non-existence isn't
>a crucial precondition but a way to get a hint.

Sounds like guessing.  I don't have the time right now, but want to 
actually dive in and try understand the intend of the maps usage before 
messing with it or ripping it out.


># ># But I am a bit suspicious about the devices that you ignore - 
># ># could you perhaps elaborate more on that, to help ensure that they 
># ># are universally sane to ignore?
># >Hm, I'd say, I just ignore path endings that aren't (at least for 
># >me) any devices.. As I said, no warranty that my patches will work 
># >w/o flaws for anyone else..
>#
># Fair enough.  I will then investigate closer before applying to 
># official yaird, to ensure not risking stability.
>My approach was: look out for devices I have, what is present in
>sysfs and which matches yaird depends on. Then I used the match
>loop and combined those matches w/ what is available in sysfs.
>That way it seemed quite clear which devices and paths are the ones
>yaird is depending on (locally, on my setup). There were symlinks
>and location changes in the sysfs, but - obviously - the devices
>are there and yaird had to be made to find them w/ the latest kernel.
>The rest was adaptation of matches and ignores within the loop.

Yes, I suspected that approach.  While it might be fine for your 
personal use of yaird (and for my laptop too), more cautious approach is 
needed for official yaird releases:

What I found in yaird (compared to other ramdisk generators) was not 
only very compact output, but also a design principle of high 
reliability: Skipping items too aggressively might be harmless for your 
and my hardware configurations, but fatal for someone elses.



># I have made little progress since then, but do not consider it dead.
># YMMV.
>Hm, my impression is it'd be interesting to re-implement yaird using an 
>abstraction layer of some sort to alleviate the tedious and returning 
>burden of kernel adaption.. some unit-testing to ensure backward compat 
>might ease the change..

I have not yet succeeded wrapping my mind around the logic of coding 
unit tests.  Would be lovely if you could help with that!

I notice you subscribed to the mailinglist.  Let's discuss that idea 
further there, as it is off-topic for this bugreport.


Regards,

  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/yaird-devel/attachments/20100610/eeac96df/attachment.pgp>