One Laptop Per Child power/battery driver
PATCH 8/8 One Laptop Per Child power/battery driver
This probably should be marked as BROKEN because, according to David Woodhouse, EC-acccess method will change. Plus currently it lacks mutexes. So this driver is just for reference. Converted from the battery-2.6 repository, 1:1.
But nevertheless it should work.
--- drivers/power/Kconfig | 6 + drivers/power/Makefile | 1 + drivers/power/olpc_battery.c | 300 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 307 insertions(+), 0 deletions(-) create mode 100644 drivers/power/olpc_battery.c
drivers/power/Kconfig +6 -0
@@ -42,4 +42,10 @@ config BATTERY_PMU Say Y here to expose battery information on Apple machines through the generic battery class. +config BATTERY_OLPC + tristate "One Laptop Per Child battery" + depends on X86_32 + help + Say Y to enable support for the battery on the $100 laptop. + endif # POWER_SUPPLY
drivers/power/Makefile +1 -0
@@ -19,3 +19,4 @@ obj-$(CONFIG_APM_POWER) += apm_power.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o +obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
drivers/power/olpc_battery.c new file +300 -0
300 lines not on this page · raw message
Signature · 1 line
1.5.1.1-dirty
Hi!
Quoted 45 lines
This probably should be marked as BROKEN because, according to David Woodhouse, EC-acccess method will change. Plus currently it lacks mutexes. So this driver is just for reference. Converted from the battery-2.6 repository, 1:1.
But nevertheless it should work.
Signed-off-by Anton Vorontsov <[email protected]>--- drivers/power/Kconfig | 6 + drivers/power/Makefile | 1 + drivers/power/olpc_battery.c | 300 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 307 insertions(+), 0 deletions(-) create mode 100644 drivers/power/olpc_battery.cdrivers/power/Kconfig +6
-0@@ -42,4 +42,10 @@ config BATTERY_PMU Say Y here to expose battery information on Apple machines through the generic battery class. +config BATTERY_OLPC + tristate "One Laptop Per Child battery" + depends on X86_32 + help + Say Y to enable support for the battery on the $100 laptop. + endif # POWER_SUPPLYdrivers/power/Makefile +1
-0@@ -19,3 +19,4 @@ obj-$(CONFIG_APM_POWER) += apm_power.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o +obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.odrivers/power/olpc_battery.c new file +0
-0
drivers/power/olpc_battery.c line 4
Quoted 4 lines
drivers/power/olpc_battery.c new file +4
-0@@ -0,0 +1,300 @@ +/* +* Battery driver for One Laptop Per Child ($100 laptop) board. +* +* Copyright ?? 2006 David Woodhouse <[email protected]>
Can we stick to ascii in sources?
drivers/power/olpc_battery.c
Quoted 4 lines
drivers/power/olpc_battery.c new file +4
-0+#define wBAT_VOLTAGE 0xf900/* *9.76/32, mV */ +#define wBAT_CURRENT 0xf902/* *15.625/120, mA */ +#define wBAT_TEMP 0xf906/* *256/1000, ??C */ +#define wAMB_TEMP 0xf908/* *256/1000, ??C */
Ascii? And those defines seem affected by hungarian convention.
drivers/power/olpc_battery.c line 32
Quoted 11 lines
drivers/power/olpc_battery.c new file +11
-0+#define sMBAT_STATUS 0xfaa4 +#define sBAT_PRESENT 1 +#define sBAT_FULL 2 +#define sBAT_DESTROY 4/* what is this exactly? */ +#define sBAT_LOW 32 +#define sBAT_DISCHG 64 +#define sMCHARGE_STATUS 0xfaa5 +#define sBAT_CHARGE 1 +#define sBAT_OVERTEMP 4 +#define sBAT_NiMH 8 +#define sPOWER_FLAG 0xfa40
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 54 lines · Pavel Machek
Hi!
Quoted 45 lines
This probably should be marked as BROKEN because, according to David Woodhouse, EC-acccess method will change. Plus currently it lacks mutexes. So this driver is just for reference. Converted from the battery-2.6 repository, 1:1.
But nevertheless it should work.
Signed-off-by Anton Vorontsov <[email protected]>--- drivers/power/Kconfig | 6 + drivers/power/Makefile | 1 + drivers/power/olpc_battery.c | 300 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 307 insertions(+), 0 deletions(-) create mode 100644 drivers/power/olpc_battery.cdrivers/power/Kconfig +6
-0@@ -42,4 +42,10 @@ config BATTERY_PMU Say Y here to expose battery information on Apple machines through the generic battery class. +config BATTERY_OLPC + tristate "One Laptop Per Child battery" + depends on X86_32 + help + Say Y to enable support for the battery on the $100 laptop. + endif # POWER_SUPPLYdrivers/power/Makefile +1
-0@@ -19,3 +19,4 @@ obj-$(CONFIG_APM_POWER) += apm_power.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o +obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.odrivers/power/olpc_battery.c new file +0
-0drivers/power/olpc_battery.c line 4
Quoted 4 lines
drivers/power/olpc_battery.c new file +4
-0@@ -0,0 +1,300 @@ +/* +* Battery driver for One Laptop Per Child ($100 laptop) board. +* +* Copyright ?? 2006 David Woodhouse <[email protected]> Can we stick to ascii in sources?
Quoted 6 lines
drivers/power/olpc_battery.c
Quoted 4 lines
drivers/power/olpc_battery.c new file +4
-0+#define wBAT_VOLTAGE 0xf900/* *9.76/32, mV */ +#define wBAT_CURRENT 0xf902/* *15.625/120, mA */ +#define wBAT_TEMP 0xf906/* *256/1000, ??C */ +#define wAMB_TEMP 0xf908/* *256/1000, ??C */ Ascii? And those defines seem affected by hungarian convention.
That's up to David Woodhouse. In my code I'm using (c), though David insisting on true "(c)" symbol. So, this is copyright thing, I can't resist to the author.
Quoted 18 lines
drivers/power/olpc_battery.c line 32
Quoted 11 lines
drivers/power/olpc_battery.c new file +11
-0+#define sMBAT_STATUS 0xfaa4 +#define sBAT_PRESENT 1 +#define sBAT_FULL 2 +#define sBAT_DESTROY 4/* what is this exactly? */ +#define sBAT_LOW 32 +#define sBAT_DISCHG 64 +#define sMCHARGE_STATUS 0xfaa5 +#define sBAT_CHARGE 1 +#define sBAT_OVERTEMP 4 +#define sBAT_NiMH 8 +#define sPOWER_FLAG 0xfa40Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Signature · 4 lines
Anton Vorontsov email: [email protected] backup email: [email protected] irc://irc.freenode.org/bd2
Quoted 1 line · Pavel Machek
Can we stick to ascii in sources?
No. Please join us in the 21st century.
Signature · 1 line
dwmw2
Quoted 4 lines · David Woodhouse
Quoted 1 line · Pavel Machek
Can we stick to ascii in sources?
No. Please join us in the 21st century.
We had this discussion before. Kernel sources should be us-ascii. utf-8 is ok for documentation.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 2 lines · Pavel Machek
We had this discussion before. Kernel sources should be us-ascii. utf-8 is ok for documentation.
/* This _is_ documentation. Go away. */
Signature · 1 line
dwmw2
Quoted 5 lines · David Woodhouse
Quoted 2 lines · Pavel Machek
We had this discussion before. Kernel sources should be us-ascii. utf-8 is ok for documentation.
/* This _is_ documentation. Go away. */
No, that's a comment. Fix your code.
(And besides, comments are supposed to be useful. Patch contained something like...
int voltage; /* ??V */
...which is pretty unhelpful. We still stick to 80 columns in the code, and bigger displays certainly predate utf-8 compatibility. Plus, you'd have to convert large part of Czech republic before I could reasonably use utf-8).
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 4 lines
...which is pretty unhelpful. We still stick to 80 columns in the code, and bigger displays certainly predate utf-8 compatibility. Plus, you'd have to convert large part of Czech republic before I could reasonably use utf-8).
Maybe its about time they started. And since you can flip an editor into utf-8 for working on kernel code its not a big deal.
Quoted 12 lines · Pavel Machek
Quoted 5 lines · David Woodhouse
Quoted 2 lines · Pavel Machek
We had this discussion before. Kernel sources should be us-ascii. utf-8 is ok for documentation.
/* This _is_ documentation. Go away. */
No, that's a comment. Fix your code.
(And besides, comments are supposed to be useful. Patch contained something like...
Quoted 7 lines
int voltage; /* ??V */
...which is pretty unhelpful. We still stick to 80 columns in the code, and bigger displays certainly predate utf-8 compatibility. Plus, you'd have to convert large part of Czech republic before I could reasonably use utf-8).
Pavel
I agree that it's really sad that anyone applies his own caprice in source code which is supposed to be used by anybody. Next time this crap will appear in printks and we will say "hey, it's documentation". It would be better to stick to the common denominator. Some people like Davem insist a lot on respecting the 80 columns limit for good reason. We should also respect the charset supported by the same terminals.
Otherwise, if anything is allowed in comments, I don't see why we should not start to put ASCII art "just for fun", since I do not see any justified use of the UTF8 on the code above.
And no, I won't upgrade my system to get UTF8 support.
Willy
Quoted 8 lines · Pavel Machek
Quoted 4 lines · David Woodhouse
Quoted 1 line · Pavel Machek
Can we stick to ascii in sources?
No. Please join us in the 21st century.
We had this discussion before. Kernel sources should be us-ascii. utf-8 is ok for documentation.
Hmmm ... what if David was German and had a couple of umlauts in his name :-) One would expect to at least _spell_ his own name properly in his code. Sources need to take care of that too (but we better stick to only UTF-8 for source files, wouldn't want to introduce ISO-8859-1 into the mix too :-)
Quoted 5 lines · Satyam Sharma
Hmmm ... what if David was German and had a couple of umlauts in his name :-) One would expect to at least _spell_ his own name properly in his code. Sources need to take care of that too (but we better stick to only UTF-8 for source files, wouldn't want to introduce ISO-8859-1 into the mix too :-)
Well, my name has an acute above "o" and a dot above "z", but I do not
have such a high expectation as to have it correctly spelled in comments and elsewhere within some code before I am able to get it right in official documents issued in English. And the universe is not going to collapse because of the missing accents, so I consider this an issue we can think of resolving once we have fixed all the bugs that we have.
Maciej
Quoted 12 lines · Maciej W. Rozycki
Quoted 7 lines · Satyam Sharma
Hmmm ... what if David was German and had a couple of umlauts in his name :-) One would expect to at least _spell_ his own name properly in his code. Sources need to take care of that too (but we better stick to only UTF-8 for source files, wouldn't want to introduce ISO-8859-1 into the mix too :-)
Quoted 11 lines
Well, my name has an acute above "o" and a dot above "z", but I do not have such a high expectation as to have it correctly spelled in comments and elsewhere within some code before I am able to get it right in official documents issued in English. And the universe is not going to collapse because of the missing accents, so I consider this an issue we can think of resolving once we have fixed all the bugs that we have.
Maciej
-
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/
Well stated!
Signature · 3 lines
"They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)
Quoted 6 lines · Maciej W. Rozycki
Well, my name has an acute above "o" and a dot above "z", but I do not
have such a high expectation as to have it correctly spelled in comments and elsewhere within some code before I am able to get it right in official documents issued in English. And the universe is not going to collapse because of the missing accents, so I consider this an issue we can think of resolving once we have fixed all the bugs that we have.
It's not an issue which needs resolving. We can spell your name just fine; we just need Pavel to quit whining and join us in the 21st century.
Signature · 1 line
dwmw2
Quoted 3 lines · David Woodhouse
It's not an issue which needs resolving. We can spell your name just fine; we just need Pavel to quit whining and join us in the 21st century.
I am pretty darn sure my name can be spelled correctly, but can it be
reasonably assured to be printed correctly on a reasonable subset of systems out there? Considering Linux only -- does our text-mode VGA console driver make any effort to print an arbitrary UTF-8-encoded text correctly? What does it do when it runs beyond the limit of 512 characters? And how about serial terminals?
When such issues are resolved and a reasonable subset of people, say 80%,
either have or can make -- without unnecessary hassle -- their systems working properly in this respect, I can start thinking about using the correct spelling of my name.
Until then I would rather work on code, sorry. And that is not going to
be any code related to UTF-8 either, but I do encourage anybody who really cares about it to address any or all issues raised above. :-)
Maciej
Quoted 3 lines · Maciej W. Rozycki
I am pretty darn sure my name can be spelled correctly, but can it be
reasonably assured to be printed correctly on a reasonable subset of systems out there?
Yes. I haven't used a system on which it cannot for a number of years.
Quoted 4 lines
Considering Linux only -- does our text-mode VGA console driver make any effort to print an arbitrary UTF-8-encoded text correctly? What does it do when it runs beyond the limit of 512 characters?
I've no idea -- I haven't used the VGA text-mode console for years either. I rarely even sit in front of a box on which it even works -- all the workstations I have these days are PowerPC, and use fbdev.
Quoted 1 line
And how about serial terminals?
It works fine over serial terminals. Why wouldn't it?
Quoted 3 lines
Until then I would rather work on code, sorry. And that is not going to
be any code related to UTF-8 either, but I do encourage anybody who really cares about it to address any or all issues raised above. :-)
You mean the VGA text console 'issue'? I might if I had suitable hardware, or if it was important. But it isn't something that bothers me.
Signature · 1 line
dwmw2
Hi!
Quoted 8 lines
Quoted 4 lines
Considering Linux only -- does our text-mode VGA console driver make any effort to print an arbitrary UTF-8-encoded text correctly? What does it do when it runs beyond the limit of 512 characters?
I've no idea -- I haven't used the VGA text-mode console for years either. I rarely even sit in front of a box on which it even works -- all the workstations I have these days are PowerPC, and use fbdev.
Even with fbdev... you are limited to 512 characters iirc. So.. who has authority to say which subset of utf-8 is ok?
(Plus there is still lot of vga consoles out there -- all fedora users afaict?)
Quoted 3 lines
Quoted 1 line
And how about serial terminals?
It works fine over serial terminals. Why wouldn't it?
He probably means serial terminals... like physical vt100. I used to have one (vt302 compatible or something). Most emulators still emulate vt100, and yes, vt100 predates utf-8.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 2 lines · Pavel Machek
Even with fbdev... you are limited to 512 characters iirc. So.. who has authority to say which subset of utf-8 is ok?
The user can load whatever font they want.
Quoted 2 lines
(Plus there is still lot of vga consoles out there -- all fedora users afaict?)
No, most Fedora users use X -- and _everything_ in Fedora works fine with UTF-8 and has done for years.
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
And how about serial terminals?
It works fine over serial terminals. Why wouldn't it?
He probably means serial terminals... like physical vt100. I used to have one (vt302 compatible or something). Most emulators still emulate vt100, and yes, vt100 predates utf-8.
I have a serial terminal which can only do lower case (well, actually capitals but it's all mapped to lower case since that's more useful).
When I write code on it, I can't do capital letters. But do I try to _force_ you to use only capitals because of my limited terminal?
No. I don't. I can see what you've written just fine, within the limitations of my terminal.
So why are you trying to force me not to spell things correctly?
Go away.
Signature · 1 line
dwmw2
Hi!
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
And how about serial terminals?
It works fine over serial terminals. Why wouldn't it?
He probably means serial terminals... like physical vt100. I used to have one (vt302 compatible or something). Most emulators still emulate vt100, and yes, vt100 predates utf-8.
Quoted 6 lines
I have a serial terminal which can only do lower case (well, actually capitals but it's all mapped to lower case since that's more useful).
When I write code on it, I can't do capital letters. But do I try to _force_ you to use only capitals because of my limited terminal?
If I wrote int j, J; in my code, you'd have valid case wanting me to fix it. And I simply want you to fix useless uses of utf-8. And evil uses utf8, like int voltage; /* ??V */. I do not know what is so hard to understand.
You are intentionally making code hard to read. Stop trying to merge that crap.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 16 lines · Pavel Machek
Hi!
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
And how about serial terminals?
It works fine over serial terminals. Why wouldn't it?
He probably means serial terminals... like physical vt100. I used to have one (vt302 compatible or something). Most emulators still emulate vt100, and yes, vt100 predates utf-8.
Quoted 5 lines
I have a serial terminal which can only do lower case (well, actually capitals but it's all mapped to lower case since that's more useful).
When I write code on it, I can't do capital letters. But do I try to _force_ you to use only capitals because of my limited terminal?
Quoted 7 lines
If I wrote int j, J; in my code, you'd have valid case wanting me to fix it. And I simply want you to fix useless uses of utf-8. And evil uses utf8, like int voltage; /* ??V */. I do not know what is so hard to understand.
You are intentionally making code hard to read. Stop trying to merge that crap.
It was °C, and that's IMHO better readable than some kind of "degrees C".
Only using 7bit ASCII might have been a good advice in the last millenium. But in the current millenium, most environments handle UTF-8 just fine.
And we are only talking about documentation and comments - IOW, things not visible for someone running a kernel. Code (including printk's) must stay 7bit ASCII.
In the worst case, if you managed to find a not UTF-8 capable environment for viewing the kernel sources, the few characters that are not 7bit ASCII are displayed incorrectly, and you'll have to guess which character someone might place in front of a "C" describing something named wBAT_TEMP (you will likely guess it correctly).
And it's nothing new, comments containing non 7bit ASCII characters are already present in 10 year old kernels (often, but not limited to, developer's names).
Quoted 1 line
Pavel
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedHi!
Quoted 19 lines
Quoted 19 lines
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
And how about serial terminals?
It works fine over serial terminals. Why wouldn't it?
He probably means serial terminals... like physical vt100. I used to have one (vt302 compatible or something). Most emulators still emulate vt100, and yes, vt100 predates utf-8.
Quoted 5 lines
I have a serial terminal which can only do lower case (well, actually capitals but it's all mapped to lower case since that's more useful).
When I write code on it, I can't do capital letters. But do I try to _force_ you to use only capitals because of my limited terminal?
If I wrote int j, J; in my code, you'd have valid case wanting me to fix it. And I simply want you to fix useless uses of utf-8. And evil uses utf8, like int voltage; /* ??V */. I do not know what is so hard to understand.
Quoted 5 lines
Quoted 2 lines
You are intentionally making code hard to read. Stop trying to merge that crap.
It was °C, and that's IMHO better readable than some kind of "degrees C".
It is more readable for you, and more readable on me while in desktop X. But on Zaurus and on console I see "???C", and I definitely prefer "degrees C" to _that_.
And I'm clearly not alone.
Quoted 3 lines
Only using 7bit ASCII might have been a good advice in the last millenium. But in the current millenium, most environments handle UTF-8 just fine.
Common denominator should be used. That includes 80 columns.
Quoted 3 lines
And we are only talking about documentation and comments - IOW, things not visible for someone running a kernel. Code (including printk's) must stay 7bit ASCII.
Yes, something that cafe driver breaks... it identifies to userland as "caf???"... but that's another story.
I'd add that variable names must be 7bit ASCII.
Quoted 5 lines
In the worst case, if you managed to find a not UTF-8 capable environment for viewing the kernel sources, the few characters that are not 7bit ASCII are displayed incorrectly, and you'll have to guess which character someone might place in front of a "C" describing something named
wBAT_TEMP(you will likely guess it correctly).
Yes, but it would be better to avoid it.. and guessing is much harder for ???V case (same driver).
I do not think using comments people can actually _read_ is that much to ask.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 6 lines · Pavel Machek
Quoted 2 lines
It was °C, and that's IMHO better readable than some kind of "degrees C".
It is more readable for you, and more readable on me while in desktop X. But on Zaurus and on console I see "???C", and I definitely prefer "degrees C" to _that_.
Actually, Anton's mail was broken -- I saw something like '??C' too in the _mail_ because he sent it with the wrong Content-Type: header. But that's not strictly relevant.
Not that Pavel's Luddism is strictly relevant to the real world either.
Signature · 1 line
dwmw2
Quoted 1 line · Pavel Machek
Common denominator should be used. That includes 80 columns.
Yep, that's really obsolete. Perhaps we should agree on some 100 columns? And/or 4-characters tabs maybe :-)
Signature · 1 line
Krzysztof Hałasa
Quoted 2 lines
Even with fbdev... you are limited to 512 characters iirc. So.. who has authority to say which subset of utf-8 is ok?
This is a bug in fbdev and currently under discussion as there is no sane reason to enforce the 512 symbol limit in the fbdev case (especially on a large modern system)
Quoted 2 lines
(Plus there is still lot of vga consoles out there -- all fedora users afaict?)
Fedora uses X.
Alan
--
Y sŵn y tonnau ar lan y môr
Y sŵn y gwynt yn bwrw'r dôr
Y sŵn y glaw ar y toeau
Y sŵn y storm ar y creigiau
Quoted 11 lines · Alan Cox
Quoted 2 lines
Even with fbdev... you are limited to 512 characters iirc. So.. who has authority to say which subset of utf-8 is ok?
This is a bug in fbdev and currently under discussion as there is no sane reason to enforce the 512 symbol limit in the fbdev case (especially on a large modern system)
Quoted 2 lines
(Plus there is still lot of vga consoles out there -- all fedora users afaict?)
Fedora uses X.
I run FC5 and even _without_ X (on the tty1 console, for example), UTF-8 source files turn out just _fine_ indeed. And I checked vim, emacs and *even* nano.
Quoted 9 lines · David Woodhouse
Quoted 6 lines · Maciej W. Rozycki
Well, my name has an acute above "o" and a dot above "z", but I do not
have such a high expectation as to have it correctly spelled in comments and elsewhere within some code before I am able to get it right in official documents issued in English. And the universe is not going to collapse because of the missing accents, so I consider this an issue we can think of resolving once we have fixed all the bugs that we have.
Quoted 3 lines
It's not an issue which needs resolving. We can spell your name just fine; we just need Pavel to quit whining and join us in the 21st century.
I hate to agree with Pavel, but the real issue here is you being intentionally obtuse. Naked patches are not compatible with UTF-8. To assume that UTF-8 is not converted anywhere is tantamount to the fallacy of SPF: Everyone on the net must do foo, then nirvana happens. If the code is being pulled git to git, UTF-8 is fine. Or send your patches in MIME at the very least.
-- Pete
Please don't use my work email address unless I _really_ need to be wearing my tinfoil hat when I read it.
Quoted 10 lines · Pete Zaitcev
Quoted 9 lines · David Woodhouse
Quoted 6 lines · Maciej W. Rozycki
Well, my name has an acute above "o" and a dot above "z", but I do not
have such a high expectation as to have it correctly spelled in comments and elsewhere within some code before I am able to get it right in official documents issued in English. And the universe is not going to collapse because of the missing accents, so I consider this an issue we can think of resolving once we have fixed all the bugs that we have.
Quoted 6 lines
Quoted 3 lines
It's not an issue which needs resolving. We can spell your name just fine; we just need Pavel to quit whining and join us in the 21st century.
I hate to agree with Pavel, but the real issue here is you being intentionally obtuse. Naked patches are not compatible with UTF-8.
Wrong. Of course they're compatible -- they're just applied as a byte stream. Patch and git are agnostic about file _contents_.
Git's apply-mailbox tool does honour the Content-Type: header in the mail, and it converts _comments_ to the correct charset for the repository, as well as handling RFC2047-encoding in the From: header. But it doesn't touch the patch itself.
Quoted 4 lines
To assume that UTF-8 is not converted anywhere is tantamount to the fallacy of SPF: Everyone on the net must do foo, then nirvana happens If the code is being pulled git to git, UTF-8 is fine. Or send your patches in MIME at the very least.
Some systems mangle whitespace in transit too, or even convert to HTML. I've known people who _have_ to send patches as MIME attachments to avoid having their patches converted to HTML. By your logic, we could argue that we shouldn't send patches in email at all, because it's also "tantamount to the fallacy of SPF".
But we'd be wrong -- just as you are. SPF is utterly moronic because it suddenly tries to change the rules and assumes that everyone has already changed, or it throws away valid email from unknown senders. In the case of sending patches, yes you _do_ assume that people aren't doing bizarre things to mangle them in transit, but that mangling is actually relatively rare. Not only that, but you only really care about a _single_ transit path, from you to whoever applies the patch. Which is easy enough to debug if it starts to do stupid things like converting to HTML or converting charsets.
Signature · 1 line
dwmw2
Quoted 2 lines · David Woodhouse
Please don't use my work email address unless I _really_ need to be wearing my tinfoil hat when I read it.
I'll keep it in mind, sorry.
Quoted 9 lines
But we'd be wrong -- just as you are. SPF is utterly moronic because it suddenly tries to change the rules and assumes that everyone has already changed, or it throws away valid email from unknown senders. In the case of sending patches, yes you _do_ assume that people aren't doing bizarre things to mangle them in transit, but that mangling is actually relatively rare. Not only that, but you only really care about a _single_ transit path, from you to whoever applies the patch. Which is easy enough to debug if it starts to do stupid things like converting to HTML or converting charsets.
I see your point, and it makes sense, but I'm not sure I agree completely. Maybe I'm traumatized by myterious rejects which happened to me before. Looking at the patch with vi showed absolutely no clue why it failed.
BTW, here's one odd thing Gmane is doing:
Quoted 3 lines
+ * Battery driver for One Laptop Per Child ($100 laptop) board.
+ *
+ * Copyright б╘ 2006 David Woodhouse <[email protected]>
The above is how I saw the Anton Vorontsov's message. The e-mail would be corrupted no matter the charset, so that is bad. But what about the copyright character? It's not Gmane's doing. The reason that not working is this:
Quoted 3 lines
From: Anton Vorontsov <cbou-JGs/[email protected]>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: quoted-printable
Anton took the UTF-8 text and sent it with wrong encoding. Such mismatch is the most common problem in my experience, not conversions to HTML.
-- Pete
Quoted 3 lines · Pete Zaitcev
I see your point, and it makes sense, but I'm not sure I agree completely. Maybe I'm traumatized by myterious rejects which happened to me before. Looking at the patch with vi showed absolutely no clue why it failed.
On the occasions that that happens to me, It's almost always due to stripped whitespace. If it were charset-conversion, looking at the patch should surely highlight the problem?
Quoted 1 line
BTW, here's one odd thing Gmane is doing:
Gmane didn't do that¹ -- Anton did. But it would apply just fine anyway; Anton's error only causes a _cosmetic_ issue when viewing his mail, not a problem with applying the patch.
The Content-Type: header only actually matters to git-am for the commit comments.
Signature · 5 lines
dwmw2 ¹ Although it did send me a batch of 'please confirm your mail' messages, which sucks a bit. It would be nice if it kept proper addresses in Cc.
Quoted 8 lines · On Mon, 7 May 2007 19:49:50 +0000 Pavel Machek <[email protected]> wrote:
Quoted 4 lines · David Woodhouse
Quoted 1 line · Pavel Machek
Can we stick to ascii in sources?
No. Please join us in the 21st century.
We had this discussion before. Kernel sources should be us-ascii. utf-8 is ok for documentation.
We had this discussion before. Kernel sources should use utf-8 for comments where neccessary. Many names cannot be correctly represented in US ascii, and mangling them is just plain rude.
Quoted 7 lines · Alan Cox
Quoted 4 lines · On Mon, 7 May 2007 19:49:50 +0000 Pavel Machek <[email protected]> wrote:
Quoted 3 lines · David Woodhouse
Quoted 1 line · Pavel Machek
Can we stick to ascii in sources?
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
No. Please join us in the 21st century.
We had this discussion before. Kernel sources should be us-ascii. utf-8 is ok for documentation.
We had this discussion before. Kernel sources should use utf-8 for comments where neccessary. Many names cannot be correctly represented in US ascii, and mangling them is just plain rude.
So should we all start writing our names in native alphabets? And comments too?
Signature · 1 line
Dmitry
Quoted 5 lines
Quoted 3 lines
We had this discussion before. Kernel sources should use utf-8 for comments where neccessary. Many names cannot be correctly represented in US ascii, and mangling them is just plain rude.
So should we all start writing our names in native alphabets? And comments too?
Well we do have comments in several languages already but I was only suggesting names as the comment texts do provide useful info and need to be readable.
Alan
Quoted 24 lines · Dmitry Torokhov
Quoted 21 lines · Alan Cox
Quoted 16 lines · On Mon, 7 May 2007 19:49:50 +0000 Pavel Machek <[email protected]> wrote:
Quoted 9 lines · David Woodhouse
Quoted 3 lines · Pavel Machek
Can we stick to ascii in sources?
No. Please join us in the 21st century.
We had this discussion before. Kernel sources should be us-ascii. utf-8 is ok for documentation.
Quoted 10 lines
Quoted 5 lines
We had this discussion before. Kernel sources should use utf-8 for comments where neccessary. Many names cannot be correctly represented in US ascii, and mangling them is just plain rude.
So should we all start writing our names in native alphabets? And comments too?
And while your at I think you should write all the comments and documentation in your native language as well ;-)
Signature · 3 lines
"They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)
Quoted 3 lines · Alan Cox
We had this discussion before. Kernel sources should use utf-8 for comments where neccessary. Many names cannot be correctly represented in US ascii, and mangling them is just plain rude.
I have to disagree here. It is using the native alphabet for the name which is very rude, because non-native hackers cannot read it. This is true on systems which can display the name correctly, which may come as a surprise to you. I used to receive e-mails from Mr. मयंक जैन at work. Do you know who the heck he is? I sure didn't. Beautiful gliphs though!
One peculiar thing I have observed is how all this "UTF-8 in names" nonsense is being pushed by western Europeans. Why? That's because their umlauts are grandfathered in, and because English speakers _can_ read their names approximately, simply by ignoring all the strokes above the letter (or, in Norwegians and Polaks cases, going through the letter). So do not try to pretend that "correctness" has anything to do with your demands. Nowhere the ethnocentrism comes through clearer than in demanding that everyone in the world were able to read names spelled as convenient for you and not for them.
-- Pete
Quoted 2 lines
I have to disagree here. It is using the native alphabet for the name which is very rude, because non-native hackers cannot read it. This is
I think you mean "non Amercian". The majority of the human race don't speak English, and you could probably make a good case that kernel tree should be in Chinese, Spanish or Gujerati by your logic.
Quoted 7 lines
One peculiar thing I have observed is how all this "UTF-8 in names" nonsense is being pushed by western Europeans. Why? That's because their umlauts are grandfathered in, and because English speakers _can_ read their names approximately, simply by ignoring all the strokes above the letter (or, in Norwegians and Polaks cases, going through the letter). So do not try to pretend that "correctness" has anything to do with your demands.
I find your comments racist and insulting. I trust you will be apologizing. The most clear example of where it would be polite to include names spelt properly are the Asian countries. They may well (and most do) choose to include a transliteration.
Western European names you can generally transliterate quite well (although conventions are not simple and you don't usually simply omit accent marks), in some cases you also completely break the naming in the eyes of a native speaker because the pronunciation implied is now all wrong.
Quoted 8 lines · Alan Cox
Quoted 7 lines
One peculiar thing I have observed is how all this "UTF-8 in names" nonsense is being pushed by western Europeans. Why? That's because their umlauts are grandfathered in, and because English speakers _can_ read their names approximately, simply by ignoring all the strokes above the letter (or, in Norwegians and Polaks cases, going through the letter). So do not try to pretend that "correctness" has anything to do with your demands.
Quoted 4 lines
I find your comments racist and insulting. I trust you will be apologizing. The most clear example of where it would be polite to include names spelt properly are the Asian countries. They may well (and most do) choose to include a transliteration.
Given that people can't be bothered to spell names which fall within the 7-bit ASCII space correctly, I think all this is very much a pipedream.
And yes, at the end of the day, it comes down to lazyness and whether people can be bothered to take the care required to get names correctly spelt. Much of my personal experience has been that the majority of people DO NOT seem to CARE about correctly spelling names.
Or maybe people just like repeatedly insulting me.
While you can arm people with the tools to allow them to do what you desire (to spell peoples names correctly), at the end of the day I think you'll find that most people will just not bother. It's a nice idea though.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: