Hi,
I am in a t-shirt transfering frenzy and was wondering which part of the
kernel code it would be best to have on my t-shirt.
I was looking at my favourite: netfilter code, but it is to clean, short
and simple functions, no tons of pointers, no mallocs, no hex numbers, too
many defines used. I was looking for something terribly complicated and
looking awesome to the eye.
How about we have a poll of the most frightening pieces of the kernel ?
What are your ideas?
Regards,
Maciej Soltysiak
Words by Maciej Soltysiak [Fri, Jan 03, 2003 at 02:25:09PM +0100]:
> Hi,
>
> I am in a t-shirt transfering frenzy and was wondering which part of the
> kernel code it would be best to have on my t-shirt.
> I was looking at my favourite: netfilter code, but it is to clean, short
> and simple functions, no tons of pointers, no mallocs, no hex numbers, too
> many defines used. I was looking for something terribly complicated and
> looking awesome to the eye.
>
> How about we have a poll of the most frightening pieces of the kernel ?
> What are your ideas?
>
[root@morgoth:/usr/src/linux]# egrep -ir "( fuck)|( shit)" *
and choose.
--
Jose Celestino | http://xpto.org/~japc/files/japc-pgpkey.asc
----------------------------------------------------------------
"Don't summarize. Don't abbreviate. Don't interpret." -- djb
On Fri, Jan 03, 2003 at 02:25:09PM +0100, Maciej Soltysiak wrote:
> Hi,
>
> I am in a t-shirt transfering frenzy and was wondering which part of the
> kernel code it would be best to have on my t-shirt.
> I was looking at my favourite: netfilter code, but it is to clean, short
> and simple functions, no tons of pointers, no mallocs, no hex numbers, too
> many defines used. I was looking for something terribly complicated and
> looking awesome to the eye.
>
> How about we have a poll of the most frightening pieces of the kernel ?
> What are your ideas?
egrep -ir "(on fire)" *
drivers/usb/printer.c:static char *usblp_messages[] = { "ok", "out of paper", "off-line", "on fire" };
:-)
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
Hi Maciej
On Fri, Jan 03, 2003 at 02:25:09PM +0100, Maciej Soltysiak wrote:
> Hi,
>
[...]
> How about we have a poll of the most frightening pieces of the kernel ?
> What are your ideas?
Do you like this one?
/*
* We use this if we don't have any better
* idle routine..
*/
void default_idle(void)
{
if (current_cpu_data.hlt_works_ok && !hlt_counter) {
__cli();
if (!current->need_resched)
safe_halt();
else
__sti();
}
}
Ulisses
Debian GNU/Linux: a dream come true
-----------------------------------------------------------------------------
"Computers are useless. They can only give answers." Pablo Picasso
---> Visita http://www.valux.org/ para saber acerca de la <---
---> Asociaci?n Valenciana de Usuarios de Linux <---
On Fri, Jan 03, 2003 at 03:55:14PM +0100, Matthias Schniedermeyer wrote:
> egrep -ir "(on fire)" *
>
> drivers/usb/printer.c:static char *usblp_messages[] = { "ok", "out of
> paper", "off-line", "on fire" };
A good explanation of that message by Jesse Pollard can be found here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=102893054014512&w=2
--
Anders Gustafsson - [email protected] - http://0x63.nu/
> I am in a t-shirt transfering frenzy and was wondering which part
> of the kernel code it would be best to have on my t-shirt.
You'd be better off digging through historic IOCCC gems.
--
Tomas Szepe <[email protected]>
For a halloween party a few years back, I trimmed and used panic.c (the
theme was that you had to go as something starting with K.. so I went as
a kernel panic. Tracedump on the front, source on the back, debian logo
on the sleeves.)
Its not particularly frightening looking, however.
On Fri, 2003-01-03 at 08:25, Maciej Soltysiak wrote:
> Hi,
>
> I am in a t-shirt transfering frenzy and was wondering which part of the
> kernel code it would be best to have on my t-shirt.
> I was looking at my favourite: netfilter code, but it is to clean, short
> and simple functions, no tons of pointers, no mallocs, no hex numbers, too
> many defines used. I was looking for something terribly complicated and
> looking awesome to the eye.
>
> How about we have a poll of the most frightening pieces of the kernel ?
> What are your ideas?
>
> Regards,
> Maciej Soltysiak
>
>
> -
> 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/
| On Fri, 2003-01-03 at 08:25, Maciej Soltysiak wrote:
| > Hi,
| >
| > I am in a t-shirt transfering frenzy and was wondering which part of the
| > kernel code it would be best to have on my t-shirt.
| > I was looking at my favourite: netfilter code, but it is to clean, short
| > and simple functions, no tons of pointers, no mallocs, no hex numbers, too
| > many defines used. I was looking for something terribly complicated and
| > looking awesome to the eye.
| >
| > How about we have a poll of the most frightening pieces of the kernel ?
| > What are your ideas?
(not 'code')
Take the ASCII art from the Sparc and PA-RISC die() functions, like so:
die_on_sparc: die_on_parisc:
_______________________________
< Your System ate a SPARC! Gah! >
\|/ ____ \|/ -------------------------------
"@'/ .. \`@" \ ^__^
/_| \__/ |_\ \ (xx)\_______
\__U_/ (__)\ )\/\
U ||----w |
|| ||
###
--
~Randy
Maciej Soltysiak wrote:
>Hi,
>
>I am in a t-shirt transfering frenzy and was wondering which part of the
>kernel code it would be best to have on my t-shirt.
>I was looking at my favourite: netfilter code, but it is to clean, short
>and simple functions, no tons of pointers, no mallocs, no hex numbers, too
>many defines used. I was looking for something terribly complicated and
>looking awesome to the eye.
>
>
arch/i386/mm/fault.c
/*
* Synchronize this task's top level page-table
* with the 'reference' page table.
*
* Do _not_ use "tsk" here. We might be inside
* an interrupt in the middle of a task switch..
*/
int offset = __pgd_offset(address);
pgd_t *pgd, *pgd_k;
pmd_t *pmd, *pmd_k;
pte_t *pte_k;
asm("movl %%cr3,%0":"=r" (pgd));
pgd = offset + (pgd_t *)__va(pgd);
pgd_k = init_mm.pgd + offset;
if (!pgd_present(*pgd_k))
goto no_context;
set_pgd(pgd, *pgd_k);
pmd = pmd_offset(pgd, address);
pmd_k = pmd_offset(pgd_k, address);
if (!pmd_present(*pmd_k))
goto no_context;
set_pmd(pmd, *pmd_k);
pte_k = pte_offset_kernel(pmd_k, address);
if (!pte_present(*pte_k))
goto no_context;
return;
}
--
?lvaro Lopes
---------------------
A .sig is just a .sig
Em Fri, Jan 03, 2003 at 08:32:55AM -0800, Randy.Dunlap escreveu:
> | On Fri, 2003-01-03 at 08:25, Maciej Soltysiak wrote:
> | > Hi,
> | >
> | > I am in a t-shirt transfering frenzy and was wondering which part of the
> | > kernel code it would be best to have on my t-shirt.
> | > I was looking at my favourite: netfilter code, but it is to clean, short
> | > and simple functions, no tons of pointers, no mallocs, no hex numbers, too
> | > many defines used. I was looking for something terribly complicated and
> | > looking awesome to the eye.
> | >
> | > How about we have a poll of the most frightening pieces of the kernel ?
> | > What are your ideas?
>
> (not 'code')
> Take the ASCII art from the Sparc and PA-RISC die() functions, like so:
>
>
>
> die_on_sparc: die_on_parisc:
> _______________________________
> < Your System ate a SPARC! Gah! >
> \|/ ____ \|/ -------------------------------
> "@'/ .. \`@" \ ^__^
> /_| \__/ |_\ \ (xx)\_______
> \__U_/ (__)\ )\/\
> U ||----w |
> || ||
Hey, dont forget this one:
void ipgre_err(struct sk_buff *skb, u32 info)
{
#ifndef I_WISH_WORLD_WERE_PERFECT
/* It is not :-( All the routers (except for Linux) return only
8 bytes of packet payload. It means, that precise relaying of
ICMP in the real Internet is absolutely infeasible.
Moreover, Cisco "wise men" put GRE key to the third word
in GRE header. It makes impossible maintaining even soft state for keyed
GRE tunnels with enabled checksum. Tell them "thank you".
Well, I wonder, rfc1812 was written by Cisco employee,
what the hell these idiots break standrads established
by themself???
*/
struct iphdr *iph = (struct iphdr*)skb->data;
net/ipv4/ip_gre.c::317
8)
- Arnaldo
On Fri, 3 Jan 2003, Maciej Soltysiak wrote:
> I am in a t-shirt transfering frenzy and was wondering which part of the
> kernel code it would be best to have on my t-shirt.
> How about we have a poll of the most frightening pieces of the kernel ?
How about drivers/net/sunhme.c ?
It's not scary, but it is absolutely hilarious, even to
people who don't even know C.
static void happy_meal_tcvr_write(struct happy_meal *hp,
unsigned long tregs, int reg,
unsigned short value)
{
int tries = TCVR_WRITE_TRIES;
ASD(("happy_meal_tcvr_write: reg=0x%02x value=%04x\n", reg,
value));
/* Welcome to Sun Microsystems, can I take your order please? */
if (!hp->happy_flags & HFLAG_FENABLE)
return happy_meal_bb_write(hp, tregs, reg, value);
/* Would you like fries with that? */
hme_write32(hp, tregs + TCVR_FRAME,
(FRAME_WRITE | (hp->paddr << 23) |
((reg & 0xff) << 18) | (value & 0xffff)));
while (!(hme_read32(hp, tregs + TCVR_FRAME) & 0x10000) && --tries)
udelay(20);
/* Anything else? */
if (!tries)
printk(KERN_ERR "happy meal: Aieee, transceiver MIF write
bolixed\n");
/* Fifty-two cents is your change, have a nice day. */
}
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Fri, Jan 03, 2003 at 02:25:09PM +0100, Maciej Soltysiak wrote:
> I am in a t-shirt transfering frenzy and was wondering which part of the
> kernel code it would be best to have on my t-shirt.
> I was looking at my favourite: netfilter code, but it is to clean, short
> and simple functions, no tons of pointers, no mallocs, no hex numbers, too
> many defines used. I was looking for something terribly complicated and
> looking awesome to the eye.
> How about we have a poll of the most frightening pieces of the kernel ?
> What are your ideas?
sheer bulk: include/asm-ia64/sn/sn2/shub_mmr.h
most typedefs: include/asm-ia64/sn/sn2/shub_mmr_t.h
bizarre (and ugly) idiom: fs/devfs/*.c
just plain ugly: arch/i386/kernel/cpu/mtrr/generic.c
really crusty-looking: drivers/char/*tty*.c
terrifying ultra-legacyness: drivers/ide/legacy/hd.c
fishiness: drivers/usb/serial/pl2303.c
why so much code?: drivers/char/dz.c
highly cleanup-resistant: mm/slab.c
unusual preprocessor games: kernel/cpufreq.c
contrived inefficiency: fs/proc/inode.c:proc_fill_super()
Bill
Rik,
Thanks for posting this, it was truly hilarious and a joy to behold :)
A reminder of the best on this planet, after observing the ugliest
and worst on this planet a short while ago on this mailing list..
thanks,
Nivedita
> How about drivers/net/sunhme.c ?
>
> It's not scary, but it is absolutely hilarious, even to
> people who don't even know C.
>
> static void happy_meal_tcvr_write(struct happy_meal *hp,
> unsigned long tregs, int reg,
> unsigned short value)
> {
> int tries = TCVR_WRITE_TRIES;
>
> ASD(("happy_meal_tcvr_write: reg=0x%02x value=%04x\n", reg,
> value));
>
> /* Welcome to Sun Microsystems, can I take your order please? */
> if (!hp->happy_flags & HFLAG_FENABLE)
> return happy_meal_bb_write(hp, tregs, reg, value);
>
> /* Would you like fries with that? */
> hme_write32(hp, tregs + TCVR_FRAME,
> (FRAME_WRITE | (hp->paddr << 23) |
> ((reg & 0xff) << 18) | (value & 0xffff)));
> while (!(hme_read32(hp, tregs + TCVR_FRAME) & 0x10000) && --tries)
> udelay(20);
>
> /* Anything else? */
> if (!tries)
> printk(KERN_ERR "happy meal: Aieee, transceiver MIF write
> bolixed\n");
>
> /* Fifty-two cents is your change, have a nice day. */
> }
>
>
> Rik
I vote for "panic ()" in kernel/panic.c
The panic output makes my heart sink everytime single time.
If only the Linux kernel had something as heart-warming as FreeBSD's
"diediedie ()". :D
Ranjeet Shetye
Senior Software Engineer
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> William Lee Irwin III
> Sent: Friday, January 03, 2003 3:39 PM
> To: Maciej Soltysiak
> Cc: [email protected]
> Subject: Re: [STUPID] Best looking code to transfer to a t-shirt
>
>
> On Fri, Jan 03, 2003 at 02:25:09PM +0100, Maciej Soltysiak wrote:
> > I am in a t-shirt transfering frenzy and was wondering
> which part of
> > the kernel code it would be best to have on my t-shirt. I
> was looking
> > at my favourite: netfilter code, but it is to clean, short
> and simple
> > functions, no tons of pointers, no mallocs, no hex numbers,
> too many
> > defines used. I was looking for something terribly complicated and
> > looking awesome to the eye. How about we have a poll of the most
> > frightening pieces of the kernel ? What are your ideas?
>
> sheer bulk: include/asm-ia64/sn/sn2/shub_mmr.h
> most typedefs:
> include/asm-ia64/sn/sn2/shub_mmr_t.h
> bizarre (and ugly) idiom: fs/devfs/*.c
> just plain ugly: arch/i386/kernel/cpu/mtrr/generic.c
> really crusty-looking: drivers/char/*tty*.c
> terrifying ultra-legacyness: drivers/ide/legacy/hd.c
> fishiness: drivers/usb/serial/pl2303.c
> why so much code?: drivers/char/dz.c
> highly cleanup-resistant: mm/slab.c
> unusual preprocessor games: kernel/cpufreq.c
> contrived inefficiency:
> fs/proc/inode.c:proc_fill_super()
>
> Bill
> -
> 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/
Thank you all for your suggestions, i found this very entertaining, lot
of laughs i must say. Also the ammount of 'shit' and 'fuck' words totally
blew me off :)
I think i'll put on my t-shirt:
- panic()
- risc logos (on the sides)
- printer "on fire" line (btw. 2.4.20 doesn't have "on fire", just:
"unknown error", 2.5.54 has it in drivers/usb/class/usblp.c)
- the elegant idle routine - also nice to have. maybe on the back
I'll look also through William's suggestions.
Thank you all very much.
Have a really nice day.
> If only the Linux kernel had something as heart-warming as FreeBSD's
> "diediedie ()". :D
How about this:
arch/m68k/mac/psc.c
/*
* Try to kill all DMA channels on the PSC. Not sure how this his
* supposed to work; this is code lifted from macmace.c and then
* expanded to cover what I think are the other 7 channels.
*/
void psc_dma_die_die_die(void)
{
int i;
printk("Killing all PSC DMA channels...");
for (i = 0 ; i < 9 ; i++) {
psc_write_word(PSC_CTL_BASE + (i << 4), 0x8800);
psc_write_word(PSC_CTL_BASE + (i << 4), 0x1000);
psc_write_word(PSC_CMD_BASE + (i << 5), 0x1100);
psc_write_word(PSC_CMD_BASE + (i << 5) + 0x10, 0x1100);
}
printk("done!\n");
}
On Sat, 4 Jan 2003, Maciej Soltysiak wrote:
| Thank you all for your suggestions, i found this very entertaining, lot
| of laughs i must say. Also the ammount of 'shit' and 'fuck' words totally
| blew me off :)
|
| I think i'll put on my t-shirt:
| - panic()
| - risc logos (on the sides)
| - printer "on fire" line (btw. 2.4.20 doesn't have "on fire", just:
| "unknown error", 2.5.54 has it in drivers/usb/class/usblp.c)
2.4.2 drivers/char/lp.c, line 209, has:
printk(KERN_INFO "lp%d on fire\n", minor);
| - the elegant idle routine - also nice to have. maybe on the back
--
~Randy