From: Jon S. <jon...@gm...> - 2005-07-28 16:29:35
|
On 7/28/05, Geert Uytterhoeven <ge...@li...> wrote: > On Thu, 28 Jul 2005, Antonino A. Daplas wrote: > > Jon Smirl wrote: > > > On 7/28/05, Geert Uytterhoeven <ge...@li...> wrote: > > > > On Wed, 27 Jul 2005, Linux Kernel Mailing List wrote: > > > > > > There are a couple of ways to fix this. > > > 1) Add a check to limit use of the sysfs attributes to 256 entries. I= f > > > you want more you have to use /dev/fb0 and the ioctl. More is an > > > uncommon case. > > > 2) Switch this to a binary parameter. Now you have to use tools like > > > hexdump instead of cat to work with the data. It was nice to be able > > > to use cat to see the current map. > > > > > > Does anyone have preferences for which way to fix it? > > > > Or... > > > > 3) Add another file in sysfs which specifies at what index and how man= y > > entries will be read or written from or to the cmap. With this addition= al > > sysfs file, it should be able to handle any reasonable cmap length, but > > it will take more than one reading of the color_map file. Another > > advantage is that the entire color map need not be read or written if > > only one field needs to be changed. > > > > I've attached a test patch. Let me know what you think. >=20 > I like it! ... But, a disadvantages is that it needs to store state betwe= en two > non-atomic operations. E.g. imagine two processes doing this at the same = time. Two attributes is a big problem with atomicity. If you want access to the full cmap I would switch to a binary attribute or use the existing IOCTL. Note that you can set the entire map with the new patch, you just can't read it. You can store 1-N entries at any base you want. >=20 > Gr{oetje,eeting}s, >=20 > Geert >=20 > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6= 8k.org >=20 > 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 Torv= alds > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" i= n > the body of a message to maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >=20 --=20 Jon Smirl jon...@gm... |