Re: [uClinux-dev] Disk Cache overlaying Shared Memory?
On Wed, Jan 27, 2010 at 05:26:25PM -0600, John B Moore wrote: This bug has been found and fixed. The issue was a missing SetPageDirty in ramfs_nommu_expand_for_mapping in fs/ramfs/file-nommu.c. This allowed the ramfs shared memory storage to be considered for being freed from the pagecache in shrink_active_list . This problem appears to have been fixed in later releases in the ramfs driver since the newer driver already has the SetPageDirty call added, but just in case someone else runs into this What's the patch actually ? Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] kfifo spinlock sharing
Hi, if I have a set of (40) kfifos, can I point them all to use the same spinlock? Having 40 separate spinlocks and only two threads accessing the kfifos seems a little wasteful. Thanks, Dave W This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] m68k/for-2.6.34
I added the following to the m68k for-next branch, destined for 2.6.34:
Finn Thain (13):
mac68k: cleanup
mac68k: rework SWIM platform device
pmac-zilog: cleanup
pmac-zilog: add platform driver
mac68k: replace mac68k SCC code with platform device
mac68k: move mac_esp platform device
mac68k: move macsonic and macmace platform devices
fbdev: mac_var_to_mode() fix
valkyriefb: various fixes
mac68k: start CUDA early
fbdev: add some missing mac modes
macfb: cleanup
macfb: fix 24-bit visual and stuff
Geert Uytterhoeven (2):
ataflop: Killl warning about unused variable flags
m68k: Eliminate unused variable in page_to_phys()
Julia Lawall (1):
m68k: Use DIV_ROUND_CLOSEST
Maxim Kuvyrkov (2):
m68k: Fix asm/swab.h for ColdFire
m68k: Switch to generic siginfo layout
Peter Huewe (1):
m68k: vme_scc - __init annotations
Philippe De Muyter (2):
m68k: Allow ioremapping top of memory
m68k{,nommu}/h8300: Remove obsolete comment about map_chunk
If there's anything else in m68k-queue (or anyplace else :-) you
desperately want in 2.6.34, please let me know.
Should I add the NPTL support for m68k and m68knommu, or shall I wait
for 2.6.35?
I'd also like to `get rid' of the ARAnyM support by getting it
mainlined, for 2.6.35 (if I find time). Who's gonna sign off those
patches?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] uClinux/FDPIC loader on LatticeMico32/Milkymist
Hi, Does anyone have experience with developing uClinux/FDPIC loaders? The loader we use in Milkymist [1] (a 100% open source system-on-chip, i.e. ALL Verilog HDL design files are under a free license) is merely crap, requiring the use of -Wl,-q to generate a special relocation section and then special options to strip in order to leave that relocation section in the final binary. The kernel loader then reads this section and relocates the binary itself (instead of having it done by the libc as it's supposed to be with normal FDPIC targets). This makes compiling software difficult, it's slow, and it's a kludge. It also seems to cause problems with C++. Such a hack will probably never be accepted in the vanilla Linux kernel and in uClibc. It would be nice if someone with experience with uClibc and FDPIC loaders on nommu targets could give us some help about this. It's probably easy and quick to make if you know in detail how FDPIC loaders work, but I don't. Thanks, Sébastien [1] http://www.milkymist.org ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
