Re: Any plans to add support for new features of laptops targeting Vista?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--- "John W. Linville" <linville@xxxxxxxxxx> wrote:

> On Thu, Jan 25, 2007 at 08:13:37AM -0600, Josh Boyer wrote:
> > On Thu, 2007-01-25 at 08:48 -0500, John W. Linville wrote:
> 
> > > Anyone have more technical information?  I wonder how much the
> vendors
> > > are allowed to share with us?
> > 
> > I recommend exercising caution and doing your homework when
> thinking
> > about implementing these things.
> 
> Perhaps my request for more information seemed unclear?

Some information I can add, which really is on the throwing caution to
the wind side of things (read: unionfs (dm equiv???)), is this feature
outline I brought up in the livecd arena long ago (and am only now
remotely close to testing), which could easily be adapted from the cd
to the flash+hd arena-

early boot file seperation-

One of the better complaints I've heard about particular livecds is
that they 'sound like a bag of nails' while booting.  I.e. seek
thrashing.

One way to get around that, is I believe the accelrated knoppix cloop
profiler solution from some folks in japan.

An alternate way to get similar benefits might be achieved thusly-

- when creating a livecd, do a test boot, tracking all files accessed
by the time gdmautologin aquiesses.  To be thorough, you would need to
post process this and tag with classes, and make sure other files in
the same class get included (i.e. some driver autoloads under your test
boot in qemu, and you need to make sure that alternate drivers get
added to the list).

- then, seperate these files into a seperate filesystem image on the
livecd.  For an extra 3%(?), use mkisofs sort to put these on the
outtermost part of the disc.  Now, when booting, use a unionfs of these
two filesystems, and you will (it seems in my theory) drastically
reduce seeking.  You may also choose to simply load the entire
early-boot-filesystem intoa ramdisk in a single long read.  With the
latter, you might even be able to pull the old broken raid mirror trick
to discard the ramdisk copy freeing up ram post-boot.

( yeah, very similar stuff to readahead.  Let me know if I'm not
grasping some existing functionality of readahead )

- Now, in the flash memory accelerator scenario, you can easily take
this style boot sequence, and store your early boot files in flash. 
Thus if the user dedicates some attached fast flash to the system, they
can utilize the performance benefits(?).

Anybody agree/disagree that this approach would be useful?

-dmc/jdog



 
____________________________________________________________________________________
TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux