diff for duplicates of <20080320192719.6a32386e.akpm@linux-foundation.org> diff --git a/a/1.txt b/N1/1.txt index d300272..fb24b8d 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,9 +1,9 @@ -On Fri, 21 Mar 2008 02:36:51 +0100 Michael Buesch <mb@bu3sch.de> wrote: +On Fri, 21 Mar 2008 02:36:51 +0100 Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote: > On Friday 21 March 2008 02:31:44 Alan Stern wrote: > > On Thu, 20 Mar 2008, Andrew Morton wrote: > > -> > > On Thu, 20 Mar 2008 21:36:04 -0300 Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote: +> > > On Thu, 20 Mar 2008 21:36:04 -0300 Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> wrote: > > > > > > > Well, so far so good for LEDs, but what about the other users of in_atomic > > > > that apparently should not be doing it either? @@ -41,3 +41,7 @@ current_thread_info->preempt_count on spin_lock/spin_unlock > done by defining an API. The call-context is part of any kernel API. Yup. 99.99% of kernel code manages to do this... +-- +To unsubscribe from this list: send the line "unsubscribe linux-wireless" in +the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 533d6db..3478a8a 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,32 +1,33 @@ "ref\0Pine.LNX.4.44L0.0803202126240.11234-100000@netrider.rowland.org\0" "ref\0200803210236.52063.mb@bu3sch.de\0" - "From\0Andrew Morton <akpm@linux-foundation.org>\0" + "ref\0200803210236.52063.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org\0" + "From\0Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>\0" "Subject\0Re: use of preempt_count instead of in_atomic() at leds-gpio.c\0" "Date\0Thu, 20 Mar 2008 19:27:19 -0700\0" - "To\0Michael Buesch <mb@bu3sch.de>\0" - "Cc\0Alan Stern <stern@rowland.harvard.edu>" - Henrique de Moraes Holschuh <hmh@hmh.eng.br> - David Brownell <david-b@pacbell.net> - Richard Purdie <rpurdie@rpsys.net> - linux-kernel@vger.kernel.org - Ingo Molnar <mingo@elte.hu> - Geert Uytterhoeven <geert@linux-m68k.org> - netdev@vger.kernel.org - Martin Schwidefsky <schwidefsky@de.ibm.com> - Heiko Carstens <heiko.carstens@de.ibm.com> - linux-usb@vger.kernel.org - linux-wireless@vger.kernel.org - video4linux-list@redhat.com - Stefan Richter <stefanr@s5r6.in-berlin.de> - " lm-sensors@lm-sensors.org\0" + "To\0Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>\0" + "Cc\0Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>" + Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> + David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> + Richard Purdie <rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.org> + linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org + Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org> + Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> + netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org + Martin Schwidefsky <schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> + Heiko Carstens <heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> + linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org + linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org + video4linux-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org + Stefan Richter <stefanr-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org> + " lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org\0" "\00:1\0" "b\0" - "On Fri, 21 Mar 2008 02:36:51 +0100 Michael Buesch <mb@bu3sch.de> wrote:\n" + "On Fri, 21 Mar 2008 02:36:51 +0100 Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote:\n" "\n" "> On Friday 21 March 2008 02:31:44 Alan Stern wrote:\n" "> > On Thu, 20 Mar 2008, Andrew Morton wrote:\n" "> > \n" - "> > > On Thu, 20 Mar 2008 21:36:04 -0300 Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:\n" + "> > > On Thu, 20 Mar 2008 21:36:04 -0300 Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> wrote:\n" "> > > \n" "> > > > Well, so far so good for LEDs, but what about the other users of in_atomic\n" "> > > > that apparently should not be doing it either?\n" @@ -63,6 +64,10 @@ "> You simply must always _know_, if you are allowed to sleep or not. This is\n" "> done by defining an API. The call-context is part of any kernel API.\n" "\n" - Yup. 99.99% of kernel code manages to do this... + "Yup. 99.99% of kernel code manages to do this...\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-wireless\" in\n" + "the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -4bb7d421e2e887df005e06ca14b5b44bdec604a8ff6dfce00e808ad0e0209dc9 +0d425fbfd3281c7a2dc4569ce4ce50459c198a278c7c09499232d48ce626aee3
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.