aboutsummaryrefslogtreecommitdiff
path: root/include/asm-x86_64/termbits.h
AgeCommit message (Collapse)Author
2006-12-08[PATCH] termios: Enable new style termios ioctls on x86-64Alan Cox
This turns on the split input/output speed features and arbitary baud rate handling for the x86-64 platform. Nothing should break if you use existing standard speeds. If you use the new speed stuff then you may see some drivers failing to report the speed changes properly in error cases. This will be worked on further. For the working cases this all seems happy. I'll post a test suite used to test the basic stuff as well. Patches for i386 will follow when I get a moment but are basically the same. If people could patch/test-suite other architectures and submit them that would be great. Signed-off-by: Alan Cox <alan@redhat.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-08[PATCH] tty: preparatory structures for termios revampAlan Cox
In order to sort out our struct termios and add proper speed control we need to separate the kernel and user termios structures. Glibc is fine but the other libraries rely on the kernel exported struct termios and we need to extend this without breaking the ABI/API To do so we add a struct ktermios which is the kernel view of a termios structure and overlaps the struct termios with extra fields on the end for now. (That limitation will go away in later patches). Some platforms (eg alpha) planned ahead and thus use the same struct for both, others did not. This just adds the structures but does not use them, it seems a sensible splitting point for bisect if there are compile failures (not that I expect them) Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!