Re: Scheduling tasklets from process context...
On Wednesday 06 April 2005 04:50, you wrote: > Since tasklets are typically used for bottom half processing, is it > acceptable/recommended that they be scheduled from a process context > (say an ioctl handler)? > > Should one try to minimize such scheduling and try to do things in process > context if possible, as tasklets run in interrupt context? Or is the driver > writer free to use the tasklets at will? What is recommended here? A tasklet does not run in interrupt context, it runs as a high priority thread, that is scheduled from either user or interrupt context. The purpose is mostly to defer workloads from interrupt context, to reduce the time spent with interrupts disabled. It would make sense to defer work from userspace to a tasklet if the hardware takes an unusual amount of time to process the userspace data. Correct me if I'm wrong :) Kenneth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Coding style: mixed-case
On Wednesday 06 April 2005 04:09, Matt Mackall wrote: > While there may be reasons why mixed case is suboptimal, the real > reason is that it's hard to keep track of which style is used where. > It's annoying and error-prone to have to remember the naming format > for everything in addition to its name. As most things are in a > standard style, things are made easier by having every piece of new > code follow that style and let us slowly approach uniformity. My primary concern was that of; why does the kernels own coding style deviate from that advise given in it's documentation. Other than that most mixed-case errors will be caught by the compiler, unless there is an ambiguity with other mixed-case statements; which is probably why that clause exists in the coding style documentation. > If you posted a patch for pf_locked() and friends (and note that it's > lowercase to match function-like usage), you'd probably find some > enthusiasts and some naysayers. Most of the naysayers would object on > the grounds of "it ain't broke", but if someone were to do it as part > of a series of more substantial clean-ups, it'd likely be accepted. Certainly I would like to have a go at a patch, but I must say that I do not feel particularly familiar with the code in question to make such a change. I would have risen to the challenge had this been a driver level change, but the mmu is something that I will not touch untill I feel comfortable. I feel that this is a change that would be best managed by an experienced kernel janitor. Kenneth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Coding style: mixed-case
Hi, while reading Documentation/CodingStyle for the nth time, I realized that I had read some conflicting coding style in some patch posted to the linux-kernel mailing-list; in include/linux/page-flags.h, there is a lot of defines that are apparently frowned upon: HOWEVER, while mixed-case names are frowned upon, descriptive names for global variables are a must. To call a global function "foo" is a shooting offense. Are those an exception to the rule or would for example PF_LOCKED/pf_locked be a nice replacement for PageLocked? Just wondering; with no intention to change code that I do not understand :) Kenneth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Coding style: mixed-case
Hi, while reading Documentation/CodingStyle for the nth time, I realized that I had read some conflicting coding style in some patch posted to the linux-kernel mailing-list; in include/linux/page-flags.h, there is a lot of defines that are apparently frowned upon: HOWEVER, while mixed-case names are frowned upon, descriptive names for global variables are a must. To call a global function foo is a shooting offense. Are those an exception to the rule or would for example PF_LOCKED/pf_locked be a nice replacement for PageLocked? Just wondering; with no intention to change code that I do not understand :) Kenneth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Coding style: mixed-case
On Wednesday 06 April 2005 04:09, Matt Mackall wrote: While there may be reasons why mixed case is suboptimal, the real reason is that it's hard to keep track of which style is used where. It's annoying and error-prone to have to remember the naming format for everything in addition to its name. As most things are in a standard style, things are made easier by having every piece of new code follow that style and let us slowly approach uniformity. My primary concern was that of; why does the kernels own coding style deviate from that advise given in it's documentation. Other than that most mixed-case errors will be caught by the compiler, unless there is an ambiguity with other mixed-case statements; which is probably why that clause exists in the coding style documentation. If you posted a patch for pf_locked() and friends (and note that it's lowercase to match function-like usage), you'd probably find some enthusiasts and some naysayers. Most of the naysayers would object on the grounds of it ain't broke, but if someone were to do it as part of a series of more substantial clean-ups, it'd likely be accepted. Certainly I would like to have a go at a patch, but I must say that I do not feel particularly familiar with the code in question to make such a change. I would have risen to the challenge had this been a driver level change, but the mmu is something that I will not touch untill I feel comfortable. I feel that this is a change that would be best managed by an experienced kernel janitor. Kenneth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduling tasklets from process context...
On Wednesday 06 April 2005 04:50, you wrote: Since tasklets are typically used for bottom half processing, is it acceptable/recommended that they be scheduled from a process context (say an ioctl handler)? Should one try to minimize such scheduling and try to do things in process context if possible, as tasklets run in interrupt context? Or is the driver writer free to use the tasklets at will? What is recommended here? A tasklet does not run in interrupt context, it runs as a high priority thread, that is scheduled from either user or interrupt context. The purpose is mostly to defer workloads from interrupt context, to reduce the time spent with interrupts disabled. It would make sense to defer work from userspace to a tasklet if the hardware takes an unusual amount of time to process the userspace data. Correct me if I'm wrong :) Kenneth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux dvb alps_tdlb7 removed
On Friday 11 March 2005 13:58, Juri Haberland wrote: > In article <[EMAIL PROTECTED]> you wrote: > > With version 2.6.10 the driver for the tuner frontend from ALPS TDLB7 > > was removed. > > > > Why do you think that this is a dead file? > > While I'm happy with the work you do for dvb on Linux, and I want to > > thank you for this anyway, my TV does not work anymore! :( > > > > I use a TechoTrend Premium card with that frontend on it. It worked > > fine until 2.6.10. > > Can you put it back into mainline? Is there some work to do for > > reinsertion? > > I think the driver you now need is sp8870. It's just another name for Yup you are right. If someone has a card that is no longer working, please have a look at these pages and contact the linuxtv-dvb mailing-list: http://www.linuxtv.org/wiki/index.php/Supported_DVB_cards http://www.linuxtv.org/wiki/index.php/DVB_cards_requiring_definition http://www.linuxtv.org/lists.php Kenneth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux dvb alps_tdlb7 removed
On Friday 11 March 2005 13:58, Juri Haberland wrote: In article [EMAIL PROTECTED] you wrote: With version 2.6.10 the driver for the tuner frontend from ALPS TDLB7 was removed. Why do you think that this is a dead file? While I'm happy with the work you do for dvb on Linux, and I want to thank you for this anyway, my TV does not work anymore! :( I use a TechoTrend Premium card with that frontend on it. It worked fine until 2.6.10. Can you put it back into mainline? Is there some work to do for reinsertion? I think the driver you now need is sp8870. It's just another name for Yup you are right. If someone has a card that is no longer working, please have a look at these pages and contact the linuxtv-dvb mailing-list: http://www.linuxtv.org/wiki/index.php/Supported_DVB_cards http://www.linuxtv.org/wiki/index.php/DVB_cards_requiring_definition http://www.linuxtv.org/lists.php Kenneth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
