diff for duplicates of <200809082114.01347.david-b@pacbell.net> diff --git a/a/1.txt b/N1/1.txt index 0d6380d..51d2408 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,18 +1,17 @@ On Monday 08 September 2008, David Miller wrote: -> > > > > =A0=A0=A0=A0struct rtc_device *rtc =3D rtc_class_open("rtc0")= -; -> >=20 +> > > > > struct rtc_device *rtc = rtc_class_open("rtc0"); +> > > > One more point: that should probably use CONFIG_RTC_HCTOSYS_DEVICE > > instead of hard-wiring to "rtc0". Yeah, I'm sure your SPARCs have > > lots of RTCs to choose from -- not! -- but I'd like to see you end > > up with code that many folk can reuse/recycle/pirate. ;) ->=20 +> > Can you be more specific? Oh, you want me to use the string defined > by that config option. Ok :-) ->=20 +> > But as far as I can tell this will only be set of RTC_HCTOSYS and > users currently are allowed to not set that. ->=20 +> > If this code goes somewhere generic you would need to ifdef test on > that, depending upon where you'd want to put it and how it would > be provided generically. @@ -21,19 +20,19 @@ OK. > > > > I'd be tempted to cache that ... notice how you never -> > > > close it, too. =A0That will goof lots of refcounts... -> > >=20 +> > > > close it, too. That will goof lots of refcounts... +> > > > > > Well if I cache it then we'll hold it forever and that's not > > > so nice right? -> >=20 +> > > > Why wouldn't it be, so long as it's eventually closed > > to prevent leakage? Other code can rtc_class_open() too; > > unlike a userspace open("/dev/rtc0", ...) this isn't an > > exclusive operation. ->=20 +> > When would be "eventually closed" if I open it here and remember > the pointer in a static local variable, and don't close it? ->=20 +> > I guess you need to be more specific about what you mean by > caching :) @@ -51,26 +50,18 @@ may not be measurable. > > supposed to happen is that you start getting an -ENODEV return > > from your rtc_set_mmss() call, and then you close and null your > > cached handle to free up its memory. ->=20 +> > I see... god that's ugly. If you want to do this in the generic > RTC layer helper routines, -=2E.. when they get created ... +... when they get created ... -> that's fine, but I don't feel like=20 +> that's fine, but I don't feel like > adding all sorts of stuff like that to the sparc specific routine > at the moment. ->=20 +> > I'm trying to do things that are practical and that I can check > into sparc-next-2.6 right now. OK by me. - - - --- -To unsubscribe from this list: send the line "unsubscribe linux-parisc"= - in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 697a0ab..a13f655 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -14,20 +14,19 @@ "\00:1\0" "b\0" "On Monday 08 September 2008, David Miller wrote:\n" - "> > > > > =A0=A0=A0=A0struct rtc_device *rtc =3D rtc_class_open(\"rtc0\")=\n" - ";\n" - "> >=20\n" + "> > > > > \302\240\302\240\302\240\302\240struct rtc_device *rtc = rtc_class_open(\"rtc0\");\n" + "> > \n" "> > One more point: that should probably use CONFIG_RTC_HCTOSYS_DEVICE\n" "> > instead of hard-wiring to \"rtc0\". Yeah, I'm sure your SPARCs have\n" "> > lots of RTCs to choose from -- not! -- but I'd like to see you end\n" "> > up with code that many folk can reuse/recycle/pirate. ;)\n" - ">=20\n" + "> \n" "> Can you be more specific? Oh, you want me to use the string defined\n" "> by that config option. Ok :-)\n" - ">=20\n" + "> \n" "> But as far as I can tell this will only be set of RTC_HCTOSYS and\n" "> users currently are allowed to not set that.\n" - ">=20\n" + "> \n" "> If this code goes somewhere generic you would need to ifdef test on\n" "> that, depending upon where you'd want to put it and how it would\n" "> be provided generically.\n" @@ -36,19 +35,19 @@ "\n" "\n" "> > > > I'd be tempted to cache that ... notice how you never\n" - "> > > > close it, too. =A0That will goof lots of refcounts...\n" - "> > >=20\n" + "> > > > close it, too. \302\240That will goof lots of refcounts...\n" + "> > > \n" "> > > Well if I cache it then we'll hold it forever and that's not\n" "> > > so nice right?\n" - "> >=20\n" + "> > \n" "> > Why wouldn't it be, so long as it's eventually closed\n" "> > to prevent leakage? Other code can rtc_class_open() too;\n" "> > unlike a userspace open(\"/dev/rtc0\", ...) this isn't an\n" "> > exclusive operation.\n" - ">=20\n" + "> \n" "> When would be \"eventually closed\" if I open it here and remember\n" "> the pointer in a static local variable, and don't close it?\n" - ">=20\n" + "> \n" "> I guess you need to be more specific about what you mean by\n" "> caching :)\n" "\n" @@ -66,28 +65,20 @@ "> > supposed to happen is that you start getting an -ENODEV return\n" "> > from your rtc_set_mmss() call, and then you close and null your\n" "> > cached handle to free up its memory.\n" - ">=20\n" + "> \n" "> I see... god that's ugly. If you want to do this in the generic\n" "> RTC layer helper routines,\n" "\n" - "=2E.. when they get created ...\n" + "... when they get created ...\n" "\n" "\n" - "> \tthat's fine, but I don't feel like=20\n" + "> \tthat's fine, but I don't feel like \n" "> adding all sorts of stuff like that to the sparc specific routine\n" "> at the moment.\n" - ">=20\n" + "> \n" "> I'm trying to do things that are practical and that I can check\n" "> into sparc-next-2.6 right now.\n" "\n" - "OK by me.\n" - "\n" - "\n" - "\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-parisc\"=\n" - " in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + OK by me. -f0f24377b51abfbc584f55b9bf44ae9c20eb757c75956112322ac80c97000cf3 +4ad1cac889da52fd6a066e8ff9ea5d95ed9cc8986c492805c552b8e37f8b9fb3
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.