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
signature.asc
Description: Digital signature
