Since we are past 2.5.0 point, I hope this patch have better chances,
at least for 2.5.x :-)
Primary purpose of this patch is to make KERN_WARNING and
KERN_INFO log levels closer to their original meaning.
Today they are quite far from what was intended.
Just look what kernel writes at the WARNING level
each time you boot your box!
When I was making this patch I couldn't resist and fixed
messed up tabs around affected printks, wrapped some
lines longer than 80 columns, fixed some typos.
My formatting preferences:
* log entries are started with capital letters except for
function/modules names in lowercase or acronyms (IDE etc)
* Dot before \n is a waste of space
* colon style: "Foo: blah blan" (not "Foo : blah" or "Foo: Blah")
But I'm not a religious fanatic: it ok to disagree with me :-)
You can see in the patch that I wasn't overly distracted
by this decorative work.
I'm doing my best trying not to break working code.
However, if you feel paranoid today you may remove
any hunk of this patch you may deem suspicious
and apply the rest - all these changes are independent
of each other, you may even just ignore rejects
if you are patching newer/older kernel!
If you like this patch but have more interesting things to play with,
you may do the following:
* clear your logs
* reconfigure syslogd to spew warnings to /var/log/syslog.warnings
* reboot
* mail boot time "warnings" which you think are not warnings but
info only ("104-key keyboard detected"-type msgs) to me -
I'll add fixes for those to this patch
Go to: http://port.imtp.ilyichevsk.odessa.ua/linux/vda/
--
vda
Linus refused wholesale cleanups in the past. Try to identify
worst offenders and start from those, and work through component
maintainers. It's a lot more work, but you have to tough it out.
-- Pete
> When I was making this patch I couldn't resist and fixed
> messed up tabs around affected printks, wrapped some
> lines longer than 80 columns, fixed some typos.
On Tuesday 27 November 2001 15:58, Pete Zaitcev wrote:
> Linus refused wholesale cleanups in the past. Try to identify
> worst offenders and start from those, and work through component
> maintainers. It's a lot more work, but you have to tough it out.
This patch can be split into individual patches right at any hunk boundary.
I think any interested maintainer can take it and apply relevant parts (or as
a whole, since their diffs for Linus are most probaly made only from relevant
kernel subtrees (they won't propagate unwanted modifications))
Anyway, it's only printks.
--
vda
Well, I don't know if it is really a bug.
Create a directory like this:
# ls -la
total 12
drwxr-sr-x 2 pochini root 4096 Nov 28 16:33 .
drwxr-xr-x 32 pochini users 8192 Nov 28 16:25 ..
Sgid bit is set and the directory is owned by me and the
group is root (yes, it shouldn't be).
When I create a file here, it gets the root group even
if I don't belong to it.
[kernel 2.4.5]
Bye.
Giuliano Pochini wrote:
> Well, I don't know if it is really a bug.
>
> Create a directory like this:
>
> # ls -la
> total 12
> drwxr-sr-x 2 pochini root 4096 Nov 28 16:33 .
> drwxr-xr-x 32 pochini users 8192 Nov 28 16:25 ..
>
> Sgid bit is set and the directory is owned by me and the
> group is root (yes, it shouldn't be).
>
> When I create a file here, it gets the root group even
> if I don't belong to it.
That's the correct behavior. Quoting "man mount":
grpid or bsdgroups / nogrpid or sysvgroups
These options define what group id a newly created file
gets. When
grpid is set, it takes the group id of the directory in
which it is
created; otherwise (the default) it takes the fsgid of the
current pro-
cess, unless the directory has the setgid bit set, in
which case it
takes the gid from the parent directory, and also gets the
setgid bit
set if it is a directory itself.
Jordan Russell