osandov

This was great. Before Powder Game, there were several games in this genre, and a very active Falling Sand Game BBS forum. I got my start in programming by writing mods for one of those games, Burning Sand. I wonder if anyone from those forums is around here...

It should work on ARM with a couple of caveats:

* Stack tracing needs architecture-specific support which is currently only implemented for x86-64 and ppc64. It's not too hard to add for other architectures, so if this is a feature you need, please open a GitHub issue and I'll get around to it soon. * 32-bit ARM doesn't support /proc/kcore, so drgn can't do live kernel debugging on 32-bit ARM. This seems to be due to historical reasons rather than any technical limitations, so I may send a patch to enable /proc/kcore for future kernel releases. AArch64 doesn't have this issue.

Userspace application debugging with drgn also has a couple of limitations mentioned in the blog post, namely the lack of breakpoints and stack tracing for live processes. Again, feel free to open issues asking for these so I know to move them up my todo list.

Some folks at Delphix implemented a debugger based on mdb that's powered by drgn: https://github.com/delphix/sdb

Absolutely, same goes for anyone else who comes across this and is interested in kernel development.

Feel free to email me at $my_username@$my_username.com. I'd be happy to help you get started.

It was actually fixed in Python 3.4 with the switch to use SipHash, as the randomization introduced in Python 3.3 was still susceptible to some attacks. See https://www.python.org/dev/peps/pep-0456/

The filesystem track at LSF/MM tends to focus on topics which impact more of the kernel than one specific filesystem, and we didn't have any of those topics for Btrfs this year. Plus, only a couple of the Btrfs developers were at LSF/MM this year, and we typically sync up via other means.

Every subsystem is tested differently. Because of the wide variety of subsystems and workflows in the kernel, it's pretty much impossible to have a single test suite you can run and call good. For example, some subsystems have unit tests that run in the kernel at boot time if you compiled the kernel with a specific config option (e.g., Btrfs [1] and ftrace [2]). Additionally, some subsystems have integration tests where we set stuff up and run from userspace. Filesystems use xfstests [3] and the block layer has something similar [4]. For the most part, developers and maintainers run these before sending patches or pull requests. Additionally, Intel operates an automated system [5] which runs several test suites and reports the results to developers.

1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

3: https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/

4: https://github.com/osandov/blktests

5: https://01.org/lkp/documentation/0-day-test-service

What problems have you had with Btrfs recently?

-fstrict-overflow is the opposite of what the parent comment was asking about. You want -fwrapv or -fno-strict-overflow.

File modes are typically written in octal, not hex.

> I don't get why BFQ hasn't been mainlined yet

BFQ hasn't been mainlined because it is written for the legacy block layer in the Linux kernel, which will be replaced entirely with the new block multiqueue implementation. It doesn't make much sense to replace CFQ or add a brand new scheduler only to rip it out in a few releases. Linux 4.11 will have support for I/O scheduling for blk-mq. BFQ is currently being ported to blk-mq; that work is the first big hurdle to getting it merged.

I'm curious about your NBD performance issues. When you say large number of blocks, are you talking a large filesystem? The free space cache tends to be a performance bottleneck for large filesystems, you might want to try out space_cache=v2.

Cool! I did something very similar to this a couple of years back: https://github.com/osandov/asmase. Instead of assembling to a file, I used the LLVM libraries to assemble in memory, then used ptrace to get a child process to point its instruction pointer at that machine code.

> BTW, for the specific problem of dealing with child processes, I really hope Linux adopts the Capsicum interface as FreeBSD has:

> https://www.freebsd.org/cgi/man.cgi?query=pdfork&sektion=2

Whoops, I mentioned this in another comment and missed this, but see http://lwn.net/Articles/638613/

> You could certainly imagine some kernel extensions that take all of this useful functionality and make it available in ways other than signals, leaving just signals for things you have to deal with immediately like SIGSEGV (so you can print a nice error message before quitting), but they don't exist yet.

In the SIGCHLD case, there's a proposed CLONE_FD flag to clone which would return a file descriptor instead of a PID. This fd could be read poll'd on and read from, which is much nicer than dealing with SIGCHLD. See http://lwn.net/Articles/638613/

So those kernel extensions are happening :)

Great article on LWN about this: http://lwn.net/Articles/642166/

Wow, that's pretty sweet. Any plans for trying to get that upstream?

There's also f2fs [1][2], which has a similar design but runs on flash devices with an FTL and thus takes a more middle road. It still has a log structure and tries to make things easy for the FTL by doing large, sequential, out-of-place writes whenever possible, but it takes advantage of the FTL when it makes things simpler, like for certain metadata that's easier to update as a small random write.

[1]: http://lwn.net/Articles/518988/ [2]: http://lwn.net/Articles/518718/

This is orthogonal to the argument in the article, but the "buffer overflow" example in C is incorrect. Even if sizeof(b) is smaller in the receiver than in the sender, the receiver will only read at most as many bytes as it (the receiver) thinks are in b -- whatever it got for sizeof(b). Of course, this could still lead to a truncated message, but we'd all be in pretty big trouble if you could buffer overflow a server by sending it a message larger than its recv buffer :)

This is cool! Nitpick about examples 2 and 3 - the code should return something in the else case.

Cool! Back in 2012, I got impatient and put together my own resistive touch screen for the Raspberry Pi: https://www.youtube.com/watch?v=uwEwHFglq8M. I just got a small LCD, a resistive touch panel, soldered up a microcontroller, and wrote a simple kernel module (https://github.com/osandov/raspi/tree/master/tsc2007) to get it all working. Unfortunately, I never really got around to documenting how I did it, and it looks like this makes it obsolete, but it's all for the best :)

A nitpicky tip: --help is normal execution, not an error, so the usage information should be printed to stdout, not stderr (and it should exit with a successful status). Nothing is more annoying than trying to use a convoluted program with a million flags (which should have a man page in the first place) and piping --help into less with no success.

I expected to see more night owls in the "Computer and mathematical" category, but it looks like we're more conventional than the average.