Slashdot Mirror

If it doesn't support RFCs RFC2549 and RFC1149 then you probably don't want it.

If you are having problems finding a standards-compliant device, these guys might be able to recommend one.

Method is already invented.

Method is already implemented

ping times were not so good.

And your neighbor leeching your wireless is bad enough, imagine him catching your pigeons to get his pron. ;-)

Method is already invented.

Method is already implemented

ping times were not so good.

And your neighbor leeching your wireless is bad enough, imagine him catching your pigeons to get his pron. ;-)

These and other questions lead me to believe that IPoAC is entirely VAPOR and has most likely not even been successfully implemented in the real world.

Sorry to burst your belief bubble...

It was written May of '06, but they were still working on porting the CPIP driver to Minix to upload it (proving Minix can do everything Linux can). http://www.blug.linux.no/rfc1149/

At least that's my theory.

Another tool that helps me out is LXR (http://lxr.linux.no/). I know we all use it to help us browse the kernel, but really it will browse anything. I like the ability with tabbed browsers to start my way from main following through functions and seeing where my nose ends up. I also have been known to try and follow a particular function to the end and then roll back up the tree.
--doug >

I found taking the time to snag the code and index it for the LXR allows you to click through functions quickly without needing any special C-scope type application etc. http://lxr.linux.no/ I like it since it's web based and you can plow through code from anywhere in your work area (any computers that have web access to the server w/ LXR on it). I used to create a cron driven script that would grab the source from source control once a night and index certain key versions of the code we were working on to make it readily available.

I often use LXR for understanding the kernel, but have used it for other large code bases. If you pair it with some sort of sticky note firefox add-on it becomes particularly useful.

http://lxr.linux.no/

Windows is designed by marketing. Linux is designed by F/OSS politics. Neither one cares about users. (Mac OS X does care about users, but it is still immature by kernel standards, *sigh*.)

• RFC 1149 - Standard for the transmission of IP datagrams on avian carriers
• RFC 2549 - IP over Avian Carriers with Quality of Service

And don't try to protest that homing pigeons are impractical! They have been tested in a real implementation and has actually been demonstrated to be faster than ADSL.

Woo! Show us your bits!!

Yep. Try http://lxr.linux.no/source/security/selinux/

_NSAKEY doesn't even compare to that. Linux kernel devs were falling over themselves to welcome that back door. In public, mind you.

/me goes to play America's Army on my SELinux-enabled TPM-chipped box.

Thanks for your reply.

I have none of the success shown from the Gentoo site. Here's me testing it out from Feather Linux (which I booted failsafe
so I wouldn't have IDE-SCSI emulation):
| root@tty3[knoppix]# dd if=/dev/hdc of=/dev/null
| hdc: command error: status=0x51 { DriveReady SeekComplete Error }
| hdc: command error: error=0x54
| end_request: I/O error, dev 16:00 (hdc), sector 1936
[ repeat error messages for sectors 1940, 1944, 1936, and 1940 ]
| dd: reading `/dev/hdc': Input/output error
| 1936+0 records in
| 1936+0 records out
| 991232 bytes transferred in 2.679557 seconds (369924 bytes/sec)
| root@tty3[knoppix]#

Similar IO errors if I mount it and use cp on a file. Also if I use conv=noerror to dd I just get a whole heck of a lot
of IO errors.

I did this before on the same laptop (using a different operating system--Debian Woody or Etch with a stock kernel) and
I got a far more informative error message, which is one of these ones here (from http://lxr.linux.no/source/drivers/ide/ide-cd.h#L7 07 )
| { 0x056f00, "Copy protection key exchange failure - Authentication failure" },
| { 0x056f01, "Copy protection key exchange failure - Key not present" },
| { 0x056f02, "Copy protection key exchange failure - Key not established" },
| { 0x056f03, "Read of scrambled sector without authentication" },
It was one of those. This means that the error message (well, error number) came from the drive, and that Linux was not
refusing me access to the bits on my own DVD, but my own DVD-ROM drive was.

So, is my DVD-ROM drive special? It's the DVD-ROM drive on my IBM Thinkpad T22, I don't know if it has a special name.

I have successfully played this DVD using I think Xine and the libdvdcss2 library.

This is what I mean when I say that I think that the bare DVD hardware is refusing bit-for-bit access (and therefore copying),
and it's not just the software. I think that this means that there is DRM in my hardware. I think that this might be the same
kind of thing as the DRM inside SD flash cards (the SD stands for "Secure Digital" and is the same SD in "SDMI".)

I should say that I'm not trying to be argumentative, just that overall "use this" rules (both use #define a lot and never use #define) are dumb.

CPP macros are very useful even in C++ as a code generation technique for instance. Using them as constants or inline functions is bad practice, but there are uses.

And in both languages, keep them distinct from names people might use independently. For instance, don't name a macro "current", lest you cause a newbie 15 minutes of frustration and swearing at GCC for nonsensical error messages. (I have to work that gripe into any discussion of CPP macros. ;-) )

People are only getting defensive because you're asking them difficult questions.

Inside the kernel, the software interfaces are subject to change without notice.

http://lxr.linux.no/source/Documentation/stable_ap i_nonsense.txt

So the only approved way to get support for a driver is to GPL the code and get it included there. Then, if one of the kernel maintainers feels like doing some refactoring it's their responsibility to make sure your code builds after the change is made.

Now the next question is who's responsible for running the unit test to make sure the code is really OK after the kernel was refactored. Is it the guy that wrote the code originally, has hardware samples and knows how to run the test, or the kernel maintainer who knows about the change but doesn't have hardware or the time/knowledge to test it?

And the answer is I don't know.

Well, they don't have to be so distinguished. They do need to be lexically distinct, or else the macro processor will operate over tokens that you didn't intend, but you can use any sort of captialisation you liek for your macro names.

Right. But, doing something different (say, making a macro named "current") will sometimes cause someone 15 frustrating minutes at trying to figure out what the heck the absolutely nonsensical error messages that GCC is outputting are supposed to mean.

It's useful to have the option.

I agree with this statement as I quoted it (i.e. out of context), but I think I disagree about what it means. I think it should be the user's option whether their FS operates in a case-sensitive or case-insensitive manner, but that applications should be written to deal with either.

This may mean using a different convention for the layout for your internal organization. Or you could use some sort of archive file (like TAR) that remembers case, and route your file requests through that.

Then again, most people who want case insensitive file systems tend to use GUI file managers anyway.

I guess I'm just one of those weirdos then. In fact, it's exactly when I'm using command line stuff that it'd almost be most useFUL to have a case-insensitive file system, because it means that I'm very likely to be typing file names. If I'm in a GUI program, I'm more likely to be just selecting files using the mouse, which means I don't care about sensitivity.

a) A bootstrap/bootloader.

This is a good example, although I don't really think it's part of the kernel in the context you appear to be using it (based on your mention of GRUB).

The relevant asm file is here. However, you are correct in that as I suspected, direct booting from it is no longer supported. It was historically, though.

What's a "core system service" ? ;) What's *not* a "core system service" ? Is, say, OpenGL a "core system service" ? How about if you're talking about the operating system on a console or some other device whose only purpose is to display graphics ?

As far as a (or the) conventional UNIX kernel is concerned, there is a very specific answer as to what does or does not constitute a core system service.

Memory management is another good example, but... where does something like a JVM that also does "memory management" fit into the picture ?

With a kernel written in C, it wouldn't. ;-)

d) A means of loading modules for communicating with different forms of hardware.

I'm reading this as hardware drivers. Where do drivers that run in user space fit in ?

Probably as part of the relevant application. Can you give me an example here?

e) A TCP/IP networking stack as part of it.

Consider Trumpet Winsock for Windows 3.x. Part of the kernel or not ?

Application. A userspace hack for an OS which AFAIK was never initially intended to support networking in the first place. AFAIK Trumpet was never used on anything other than fairly early dialup, and it most likely wasn't intended to be. It would have been as slow as hell compared to contemporary stacks, I'm guessing...but would have been written on the assumption that considering how slow the user's physical link was in such a scenario, they wouldn't be likely to notice anywayz. ;-)

I am surprised that this project implementing RFC 1149 has not been cited yet.

I thought about this before, and I think that Windows might be filled with so much spaghetti code and hacks that it is better not to know the crazy inner workings.

I bet they at least don't have a preprocessor macro current that caused at least one kernel newbie 20 minutes of frustration trying to figure out why in the hell the line int current; was causing compilation errors.

Yes it can, per the mere aggregation clause of both licenses. You just can't run GPL v2 code and GPL v3+ code in the same process. From GPL v2:

See also the GPL and non-free software, clarification of "mere aggregation", and use of GPL software in a proprietary system from the GPL v2 FAQ. Likewise, from the latest draft of GPL v3:

Furthermore, if you are referring to the combination of Linux with a GPL v3 application, then Linux itself is licensed under an explicit exception such that syscalls are not considered "combining" per the GPL. From the Linux license:

The GPL v3 application is licensed under the operating system exception, which is worded as follows in the current draft:

Outside of Linux, NOBODY follows this. Microsoft, Apple, Sun, everybody else publishes stable driver APIs - and guess what? People write drivers for them! I'm familiar with one OS that has a complete Microsoft DDI interface (so you could run Windows drivers on the OS). ANY proprietary driver model is closer to being a standard than the Linux model. Because Linux refuses to standardize.

Looks to me like Solaris wins Linux drivers, whereas Linux wins nothing.

... then the kernel would be encumbered by all the drawbacks of maintaining it. See http://lxr.linux.no/source/Documentation/stable_ap i_nonsense.txt for details.

Except that if the team wants to continue to use the GPL, the FSF doesn't allow modification of the wording of the GPL license...

How did Linus get away with modifying the GPL? The GPL states that:

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

And yet Linus has added:

Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.

The GPL allows me to redistribute the kernel under v3, but Linus seems to be trying to prohibit redistribution using the any later version clause if I am reading his words correctly.

What type of "advanced data structures" are you alluding to? I cant imagine needing anything more complex than say, red-black trees , in kernel development.
And as someone already pointed out, use the predefined macros. Failing that you can always check out
http://lxr.linux.no/
And to who ever made the comment about using lists in kernel source... *sigh* probably not worth it.

Half a second of lag is EXTREMELY low for what I'm familiar with in satellite internettery. Memory more lends to numbers like 7500 ms for most commerical satellite links. You'd be just as well off with IP over Carrier Pigeon for gaming.

If data compression is being handled in the kernel, there are serious design issues here.

Really?

And in this case, being 'extra careful' consists of writing sufficient tests.

And tests are good only when you run them.

You mount it in ext2 mode. ext3 is just ext2+journalling, and you can mount a ext3 partition as ext2. This doesn't replay the journal, so you won't get to see any data actually in the journal, but the rest of the data you can see.

Have you tried that? I just tried that on Linux 2.6.17-1-686 (packaged in Debian), and it doesn't work. IIRC, an ext3 filesystem is only backwards-compatible with ext2 when it's cleanly unmounted, and this behaviour is by design. Otherwise, you'd get data corruption when you try to replay the journal on a ext3 filesystem that's been modified (using an ext2 driver) since the journal was created.

And there are other ways that you can ensure that Linux will not write to the disk -- for example, `hdparm -r /dev/whatever' will tell the driver to not let Linux write to the disk, no matter what.

Yes, but it doesn't work how you might think hdparm -r sets a flag (via the BLKROSET ioctl) that is honoured by each individual filesystem driver, as well as the drive that presents block devices to user space (see ext3_load_journal in fs/ext3/super.c and open_bdev_excl in fs/block_dev.c). It is not handled by a lower layer like the IDE driver or the drive itself, unlike what you might think given that you're using hdparm.

The feature doesn't look designed to guarantee read-only operation, and I personally wouldn't consider it to be trustworthy. As you say, it doesn't seem likely that a court would take it as a given that all accesses were read-only (especially if you're trying to establish that a certain file was or wasn't deleted at a certain time). On the other hand, it's not always the rules of evidence that you're worried about. You don't want some Linux bug causing you to destroy your only copy of the information you need to solve a crime.

Come to think of it, I wonder how easy it is to modify the firmware on a hard drive these days. It would be an interesting exercise to put a dead man's switch, which wipes out some critical information and then deletes itself, into the IDE firmware. Hmm...

You mount it in ext2 mode. ext3 is just ext2+journalling, and you can mount a ext3 partition as ext2. This doesn't replay the journal, so you won't get to see any data actually in the journal, but the rest of the data you can see.

Have you tried that? I just tried that on Linux 2.6.17-1-686 (packaged in Debian), and it doesn't work. IIRC, an ext3 filesystem is only backwards-compatible with ext2 when it's cleanly unmounted, and this behaviour is by design. Otherwise, you'd get data corruption when you try to replay the journal on a ext3 filesystem that's been modified (using an ext2 driver) since the journal was created.

And there are other ways that you can ensure that Linux will not write to the disk -- for example, `hdparm -r /dev/whatever' will tell the driver to not let Linux write to the disk, no matter what.

Yes, but it doesn't work how you might think hdparm -r sets a flag (via the BLKROSET ioctl) that is honoured by each individual filesystem driver, as well as the drive that presents block devices to user space (see ext3_load_journal in fs/ext3/super.c and open_bdev_excl in fs/block_dev.c). It is not handled by a lower layer like the IDE driver or the drive itself, unlike what you might think given that you're using hdparm.

The feature doesn't look designed to guarantee read-only operation, and I personally wouldn't consider it to be trustworthy. As you say, it doesn't seem likely that a court would take it as a given that all accesses were read-only (especially if you're trying to establish that a certain file was or wasn't deleted at a certain time). On the other hand, it's not always the rules of evidence that you're worried about. You don't want some Linux bug causing you to destroy your only copy of the information you need to solve a crime.

Come to think of it, I wonder how easy it is to modify the firmware on a hard drive these days. It would be an interesting exercise to put a dead man's switch, which wipes out some critical information and then deletes itself, into the IDE firmware. Hmm...

There are the old tools of course, cscope and cflow, but also new stuff.

Check out www.opensolaris.org's source browser. Go to http://lxr.linux.no/ to see Linux in a different source browser. I know the latter is available as source; I'm pretty sure the OpenSolaris one is too.

Use the editor for editing, and the browser for browsing. Makes sense, hmmm?

Some of these things are integrated with the version control, allowing quick access to prior revisions.

I think the improvements in RFC 2549 are a big step, or flap maybe. Besides, there is already a working implementation of RFC 1149 for Linux.

When there is a unified graphics API, the driver writers have a finite set of things to test, and quality follows.

-1, Troll

Read Documentation/stable_api_nonsense.txt

Problem 2: Even if these people left them open for convenience, sharing, etc - their terms of service with their ISP almost always have a clause saying that service is to be used only be residents of the billing address. By using their connection, whether they want you to or not, you are aiding them in breaking their TOS.

I've always considered stuff like LXR (linux cross reference) to be good for this kind of thing.

LXR's claim to fame is that it started out being a cross-referenced browser for the linux kernel source code, but since it was released, the newer versions has moved towards becoming more of a general source browser. (might need to use cvs, don't know if a proper release was made)

It does neat tricks like processing source code, building function/variable/header/etc line references for usage, definition, declaration etc, and cramming them into a db for retreival. It can also handle interfacing with CVS to pull source code directly from a CVS server, which is interesting. Also handles full text searching too, if you get glimpse or whatever.

Of course, the interface to LXR is a web browser, which makes it less than ideal if you consider that it isn't integrated into an IDE, but for the purpose of tracing/searching large amounts of code, it's still pretty useful.

ash

#define BUILD_LOCK_OPS(op, locktype) \
void __lockfunc _##op##_lock(locktype##_t *lock) \
{ \
  [...] \
}

#define BUILD_LOCK_OPS(op, locktype) \
void __lockfunc _##op##_lock(locktype##_t *lock) \
{ \
  [...] \
}

http://lxr.linux.no/source/Documentation/stable_ap i_nonsense.txt

I remain unconvinced.

I remain unconvinced.

Where is this stated, in Linux 2.0?
Here.

A quick check at http://lxr.linux.no/source/COPYING reveals that this was added sometime beween 2.2.26 and 2.4.18, i.e. this was decided a long time ago and is not just a reaction to the forthcomming version 3.

Did all copyright holders agree to this change!?

Some other copyright holders in the kernel have a different policy:

.../linux_kernel/linux-2.6.15.1/fs>grep -l 'either version 2 of the License' */*.[ch] | wc
134 134 1925
.../linux_kernel/linux-2.6.15.1/fs>

A quick check at http://lxr.linux.no/source/COPYING reveals that this was added sometime beween 2.2.26 and 2.4.18, i.e. this was decided a long time ago and is not just a reaction to the forthcomming version 3.

I bet this is true for linux source code as well.

No, this is not true for the linux source code. As pointed out several times already, linux has always been released under GPLv2 only. The following text is from the COPYING file:

Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.

A quick check at http://lxr.linux.no/source/COPYING reveals that this was added sometime beween 2.2.26 and 2.4.18, i.e. this was decided a long time ago and is not just a reaction to the forthcomming version 3.

Of course, it's actually GPLv2 or later, because several source files have the "v2 or later" clause.

Huh? Linux 2.0.40 is licensed under GPLv2, which explicitly states that the licensee may choose any version of the GPL, under certain conditions (which are met for 2.0.40). The fact that Linus now claims that he never intended that doesn't make it any less binding upon him.

I'd say that this is "relative": at the start of the COPYING file , I read: "GNU GENERAL PUBLIC LICENSE Version 2, June 1991". I'd say that it looks like Linus has modified the COPYING file on purpose just to _clarify_ the original intentions.

Then you haven't read much about the subject. http://lxr.linux.no/source/Documentation/stable_ap i_nonsense.txt

That file is not part of Linux's source code distribution. This one, however, is. ;)

You should read http://lxr.linux.no/source/Documentation/stable_ap i_nonsense.txt.

1. Be explicit
2. Don't make up uncommon abreviations
3. Use a consistent naming convention and stick to it. (underbars for local names, mixed case for class names, suffexes for parameters, whatever floats your boat)
4. Learn to use your editor so your not affraid of variable names with more than 5 characters
5. 
   
   I know this is a M$ hater web site but just about any programmer can learn a thing or two by picking up the "Windows Native API Refrence" and looking at the function names. They are usually pretty long, but its generally pretty easy to understand what they do, and what the parameters they take are. For an example of bad naming conventions just look at the linux kernel source which is full of evil shit for example (not the worst) http://lxr.linux.no/source/kernel/rcupdate.c
   which has wonderful things like "call_rcu_bh()" "rcu_do_batch()". After you read the half page comment it makes sense, but some of this is just basic stuff. Plus about 50% of the functions in that module don't even have single line comment about what they do, any side effects, locking requirements to call etc...