Re: Ask for help, about the trivial patches.

[jimmy bahuleyan]

TripleX Chung wrote:
> Jesper Juhl wrote:
>> Note: my explanations below are based on how I understand these
>> things, but I'm not the trivial patch monkey nor did I help create
>> these guidelines, so I'm in no way authoritative on the subject.
>>
>> On 13/07/07, TripleX Chung <[EMAIL PROTECTED]> wrote:
>>> I am working on the chinese translated version of
>>> Documentation/SubmittingPatches and get some problem about the "Trivial
>>> patches".I can not understand what "Trivial patches" exactly means.The
>>> documentation said:
>>>
>> If you are unclear of the meaning of the word "trivial", then take a
>> look here for an explanation: http://www.m-w.com/dictionary/trivial
>>
> Thanks for your help. 
> But I still have problems.
> Trivial means "of little worth or importance". But some of the examples
> in the rules are important, like "runtime fixes". Spell fixes must be
> unimportant, but most of the runtime fixes like memory leaks or NULL
> pointers must be important. I was still a little confused with them.
> 

Literally, yes. But look at it from a s/w engineering point of view.

A NULL pointer deref is important, but it is also a *very local* and
very obvious fix (one that doesn't need extensive testing, one that
doesn't have effects spread out over many modules that requires great
amount of thought).

So such things are trivial bug-fixes.

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: Hibernation considerations

[jimmy bahuleyan]

Al Boldi wrote:
> 
> This should be the responsibility of the kexec'd hibernating kernel.  Note 
> though in (6), the normal kernel takes care of preparing devices, then the 
> hibernating kernel dumps the image and either calls S4 or S3.  On resume 
> from S3 it can immediately switch over to the normal kernel, and from S4 the 
> known bootup would occur.
> 
>> (8) Hibernation and restore should not be too slow
>>
>> In my opinion, if more than one minute is needed to hibernate the
>> system with the help of certain hibernation framework, then this framework
>> is not very useful in practice.  It might be useful to perform some
>> special tasks (eg. moving a server to another place without taking it
>> down), but it is not very useful, for example, to notebook users.
> 
> The latest hibernating kexec patches boot a kexec'd modular kernel with 
> initramfs into [EMAIL PROTECTED] in less than one second.  Switch-back is 
> almost instant.  Add to this the time required to either store or restore 
> the image, and it may be obvious that this approach isn't slower, but maybe 
> even faster than the current swsusp.
> 

What about (9)? Would it be that a user choosing to build a kernel with
hibernate support gets a additional modular kernel built (which he
should then use for resumption) or he should configure & build the
modular kernel independent of main kernel?

Or will the Linux boot procedure change so that it always goes thru a
modular part followed by kexec (just to be uniform)?

Although the kexec approach seems interesting, the final user-scenario
seems a bit complex (or confusing).

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

[jimmy bahuleyan]

Rafael J. Wysocki wrote:
[snip]
> 
> So if a user wants to install a kernel.org kernel on his system, (s)he'll have
> to compile and install two kernels with different options.
> 
> That doesn't sound good to me. :-)
> 

definitely. that sounds kind of strange, not to think of having to
remember which kernel to choose on booting.

would it be possible to have the same kernel (or image) act as both
kernel 'a' & 'b', kind of like operating in two different modes.

the kexec-style-hibernate does sound more appealing though..

> Greetings,
> Rafael

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: NPTL

[jimmy bahuleyan]

[EMAIL PROTECTED] wrote:
> So I can say that in linux 'thread' == 'process'?
> 

No. It's more like, in linux threads are visible to the kernel (unlike
in N:1 thread models, linux is 1:1). Threads are the basic unit of
scheduling.

A process can have >1 threads.

> Is kernel routine 'kthread' creating a process?
> I'm just thinking on this subject: if to create 'real threads' - will
> it increase performance? Should I ever think in this way?
> When I say 'real thread' - I mean the thread that doen't switch
> context when it's starting to run.
> 

What do you mean by context?

Each thread has it's own stack, registers, etc. which form it's context.
A process has more info like file descriptors, IPC resources, virtual
memory info. Between scheduling threads of the same process these stay same.

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: RSA support into kernel?

[jimmy bahuleyan]

Gautam Singaraju wrote:
> Is there any attempt being made to provide software based RSA
> cryptographic support in kernel? I see that Linux supports
> Hardware based cryptographic devices (VIA Padlock ACE). How is the
> performance of such hardware? How well are these devices supported?
> -GS

i fail to see why the kernel should provide software RSA support? The
hardware support that you're talking about are device drivers for chips,
not a cryptographic interface.

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: speedstep-centrino (no such device)

[jimmy bahuleyan]

Renato S. Yamane wrote:
> Hi,
> 
> Is impossible use speedstep in my Laptop with Pentium M 1,86Ghz:
> 
> #modprobe speedstep-centrino
> FATAL: Error inserting speedstep_centrino
> (/lib/modules/2.6.18-3-686/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko):
> No such device
> 
> To do that (speedstep), I need install powersaved, but
> speedstep-centrino is not used.
> 
> More information can see in:
> 
> 
> Regards,
> Renato

did you try with the latest kernel (it works on my PentiumM and kubuntu)
or is this a ubuntu specific bug?


-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: How innovative is Linux?

[jimmy bahuleyan]

Jan Engelhardt wrote:
> On Jun 25 2007 09:37, Randy Dunlap wrote:
>> On Mon, 25 Jun 2007 17:15:50 +0200 (CEST) Jan Engelhardt wrote:
>>> On Jun 25 2007 11:12, Lennart Sorensen wrote:
 It is also quite likely the reply was written before reading the other
 comments.  With the volume on lkml, reading all comments in a thread
 before writing any replies is just not possible.
>>> Perhaps the list needs to be split up, e.g. [EMAIL PROTECTED] :)
>> I'm for that (including a place for GPL discussions), but I think that
>> people would still just overload lkml instead of using the split lists.
> 
> Then turn it around: the technical part becomes a separate list. Sort of like
> netfilter and netfilter-devel.
> 
> 
>   Jan

would be quite difficult in practice, since people would then argue that
their mails were in fact technical ;)

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: How innovative is Linux?

[jimmy bahuleyan]

Grozdan Nikolov wrote:
> On Saturday 23 June 2007 19:53, you wrote:
>> On Sat, 2007-06-23 at 14:17 +0200, Grozdan Nikolov wrote:
>> [...]
>>
>>> Please CC me as I'm not subscribe to this mailing list,
>> Perhaps you should change that and find most answers for yourself.
>>
>>> Thanks!
>> Thanks!
>>
>>  Bernd
> 
> Perhaps you should change your rude attitude towards people who are seeking 
> for answers without actually looking for rants or flame-wars. If you have 
> read my replies to Alan, you should know why I asked these questions To 
> clarify something that might be incorrect or biased in the articles I've read 
> so far... if you could tell me a better place to ask about Linux internal 
> stuff, please tell me so.. 
> 

well, i would say this - put yourself into the shoes of a kernel
developer who barely has time to keep track of the large volume of
development work, discussions, testing, etc. Then someone who claims to
be not a kernel developer, who isn't subscribed to the list comes along
and says 'there is _no_ innovation in the linux kernel'. What would your
reaction be?

I'm not a kernel developer myself, but i think there are lots of
resources on the internet where you can read watered down versions of
discussions happening on this list.

> willing to answer or clarify some things to a person who's just looking for 
> the *correct* answers
> 

Of course, everyone wants to learn from the gurus. But confronting them
in this way hardly seems the right way ;)

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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/

make xconfig failure on 2.6.21.5

[jimmy bahuleyan]

Hi,

I have a Kubuntu 7.04 distro with Qt4 development packages installed.
Trying to do a 'make xconfig' fails with:

  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  CHECK   qt
*
* Unable to find the QT installation. Please make sure that
* the QT development package is correctly installed and
* either install pkg-config or set the QTDIR environment
* variable to the correct location.
*
  HOSTCC  scripts/kconfig/conf.o
sed < scripts/kconfig/lkc_proto.h > scripts/kconfig/lkc_defs.h
's/P(\([^,]*\),.*/#define \1 (\*\1_p)/'
  HOSTCC  scripts/kconfig/kconfig_load.o
  HOSTCC  scripts/kconfig/kxgettext.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
make[1]: *** No rule to make target `scripts/kconfig/.tmp_qtcheck',
needed by `scripts/kconfig/qconf.o'.  Stop.
make: *** [xconfig] Error 2


Is this a problem with my setup or that kbuild/kconfig can't handle Qt4?
I noticed that scripts/kconfig/Makefile checks for:

pkg-config --exists qt
pkg-config --exists qt-mt

whereas the Qt4 installation I have the *.pc files are:

Qt3Support.pc
QtCore.pc
QtGui.pc

and also the places where kconfig checks for qconfig.h doesn't seem to
be where Qt4 keeps it (in my installation),

/usr/share/qt4/include/QtCore/qconfig.h
/usr/share/qt4/include/Qt/qconfig.h


Anyone else run into the same problem?


-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: How innovative is Linux?

[jimmy bahuleyan]

Torsten Duwe wrote:
> On Saturday 23 June 2007, you wrote:
> 
>> hmm, wasn't loadable kernel modules first implemented in SunOS 4.x [...]
> Yes, but that was pretty cumbersome. You had to resolve the symbols in user 
> space, using a hopefully matching /vmunix. Linux was first to feature an 
> in-kernel linker and symbol table, IIRC.
> 

building upon or improving existing technology is as important as
inventing new things. if every one insisted on dreaming up new things, i
doubt we would've accomplished anything significant (not just in OS,
anywhere ;)

>   Torsten

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[jimmy bahuleyan]

Alexandre Oliva wrote:
> Here's an idea that just occurred to me, after all the discussions
> about motivations, tit-for-tat, authors' wishes and all.
> 
> If GPLv3 were to have a clause that permitted combination/linking with
> code under GPLv2, this wouldn't be enough for GPLv3 projects to use
> Linux code, and it wouldn't be enough for Linux code to use GPLv3
> projects.  That's because GPLv2 would still demand all code to be
> licensed under GPLv2, and GPLv3 wouldn't permit this.
> 
> However, if GPLv3 had a permission to combine/link with code under
> GPLv2, *and* Linux (and any other projects interested in mutual
> compatibility) introduced an additional permission to combine/link
> with code under GPLv3 (or even GPLv3+, constrained by some condition
> if you will), then:
> 

There, that right there, wouldn't it again require a 'nod' from all
those who have contributed to the kernel (because at the time they did,
the license was GPLv2 without any additions)?

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[jimmy bahuleyan]

Theodore Tso wrote:
> Basically, in the US, you get the best justice money can buy.  :-)

that has to be one of the best one-liners ever! :)

> 
>   - Ted

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: PC speaker

[jimmy bahuleyan]

Lee Revell wrote:
> On 6/12/07, R.F. Burns <[EMAIL PROTECTED]> wrote:
>> Is it possible to write a kernel module which, when loaded, will blow
>> the PC
>> speaker?
> 
> LOL.  May I ask what your use case is?
> 
or isn't it mis-use case :)

> Lee

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: Size of kernel modules

[jimmy bahuleyan]

Christoph Pleger wrote:
> Hello,
> 
[snip]
> After the new kernel package had been created, I installed it. After
> that, I looked into the directory /boot and was very surprised: The
> initial ramdisk of the new kernel was much larger than the initrd of the
> old kernel. To find out the cause for this, I investigated how
> directories /lib/modules/$old and /lib/modules/$new differ. I found out
> that the filenames are the same, but the size of the files differs very
> much. I found a module file in the new directory that was almost five
> times as large as the file with the same name in the old directory.
> 

sounds more like you have debug options enabled?

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: [PATCH] "volatile considered harmful", take 3

[jimmy bahuleyan]

Stefan Richter wrote:
> Satyam Sharma wrote:
>> Coming back to the document, we do need to document / find
>> consensus on the "preferred" way to do similar business in the
>> kernel, and my opinion as far as that is concerned is to shun
>> volatile wherever possible (which includes the case originally
>> discussed above).
> 
> I too recommend that volatile-considered-harmful.txt is not watered down
> by an ever growing "but if" list.  If anybody knows what he does, he
> still can program in a deviating way --- provided that he leaves a brief
> comment in the code, telling why it is possible and beneficial to use
> the volatile qualifier in this special case.

yes, this seems the better option. generally, the more complex rules you
have, the more people tend to break it (either through not being able t
comprehend it or cos it's too difficult to follow).

i believe, the doc here is pretty unambiguous regarding the fact that
volatile should be avoided. And as Stefan pointed out, anyone who feels
the need to use, must surely _know_ what he is doing & hence is in a
position t make that decision (followed ofcourse with a doc of why it
was done).

it would be better we didn't grow the list of exceptions - IMHO.

-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: [PATCH] "volatile considered harmful", take 2

[jimmy bahuleyan]

Johannes Stezenbach wrote:
> On Fri, May 11, 2007 at 02:08:54AM +0530, jimmy bahuleyan wrote:
>> Jonathan Corbet wrote:
>> [snip..]
>>> +
>>> +  - The jiffies variable is special in that it can have a different value
>>> +every time it is referenced, but it can be read without any special
>>> +locking.  So jiffies can be volatile, but the addition of other
>>> +variables of this type is strongly frowned upon.  Jiffies is considered
>>> +to be a "stupid legacy" issue in this regard.
>> Why is it that you consider jiffies to be a "stupid legacy"? Isn't it
>> natural to have a externally modified variable which is only /read/ to
>> be volatile? (or is jiffies supposed to be replaced with something
>> smarter/better :)
> 
> "stupid legacy" were Linus' words. http://lwn.net/Articles/233482/
> 
> How about this:
> 
> "The jiffies variable is a special case because there are too
> many places in the kernel which would have to be changed and reviewed
> if the volatile would be removed from jiffies. However, the
> use of volatile qualifier for jiffies is just as wrong as
> it is elsewhere. Don't use jiffies as an excuse to use volatile
> in your code."
> 
> 
> Johannes
> 

yes this sounds better. at least to a non-kernel expert like me it makes
the meaning clear - 'that jiffies is a special case, not to be taken as
an example for other stuff'.

-jb

-- 
Tact is the art of making a point without making an enemy.
-
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: [PATCH] "volatile considered harmful", take 2

[jimmy bahuleyan]

Jonathan Corbet wrote:
[snip..]
> +
> +  - The jiffies variable is special in that it can have a different value
> +every time it is referenced, but it can be read without any special
> +locking.  So jiffies can be volatile, but the addition of other
> +variables of this type is strongly frowned upon.  Jiffies is considered
> +to be a "stupid legacy" issue in this regard.

Why is it that you consider jiffies to be a "stupid legacy"? Isn't it
natural to have a externally modified variable which is only /read/ to
be volatile? (or is jiffies supposed to be replaced with something
smarter/better :)


-jb
-- 
Tact is the art of making a point without making an enemy.
-
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: [ck] Re: RSDL v0.31

[jimmy bahuleyan]

Mike Galbraith wrote:
> On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote:
> 
>> I'd recon KDE regresses because of kioslaves waiting on a pipe
>> (communication with the app they're doing IO for) and then expiring.
>> That's why splitting IO from an app isn't exactly smart. It should at
>> least be ran in an another thread.
> 
> Hm.  Sounds rather a lot like the...
> X sucks, fix X and RSDL will rock your world.  RSDL is perfect.
> ...that I've been getting.
> 
>   -Mike

maybe if it is possible to classify program behaviors that cause RSDL to
do bad (relatively) or the mainline scheduler to jitter, we could try
modifying the existing heuristics to get a better default scheduler.

of course, it wouldn't be able to cater to all the workloads and would
meet everybody's definition of optimal. but getting close to optimal in
most cases should be a good enough goal for linux's default sched!

i've been following this thread, and there's been many instances of
'RSDL is gr8' and 'RSDL regresses'.

maybe RSDL isn't the answer. maybe the current mainline sched isn't
either. but RSDL definitely has done *something* right.

What i think is needed is 'why this works here' and 'how to get this
behavior to work with some other possibly conflicting but important
workloads'.

(just my 2c :-)


-jb
-- 
I am professionally trained in computer science, which is to say
(in all seriousness) that I am extremely poorly educated.
-- Joseph Weizenbaum
-
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/