- 16 3月, 2008 2 次提交
-
-
由 Kyle McMartin 提交于
Commit 721fdf34 introduced a subtle bug by accidently removing the "static" from iodc_dbuf. This resulted in, what appeared to be, a trap without *current set to a task. Probably the result of a trap in real mode while calling firmware. Also do other misc clean ups. Since the only input from firmware is non blocking, share iodc_dbuf between input and output, and spinlock the only callers. Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
-
由 Kyle McMartin 提交于
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
-
- 07 12月, 2007 1 次提交
-
-
由 Kyle McMartin 提交于
There's really no reason not to print more than one character at a time to the PDC console... Booting is measurably speedier, and now I don't have to watch individual characters get drawn. Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
-
- 11 7月, 2006 1 次提交
-
-
由 Jon Smirl 提交于
MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h allows all of the framebuffer and VT console drivers to remove their dependency on tty.h. [akpm@osdl.org: fix alpha build] Signed-off-by: NJon Smirl <jonsmir@gmail.com> Signed-off-by: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 01 7月, 2006 1 次提交
-
-
由 Jörn Engel 提交于
Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 22 10月, 2005 1 次提交
-
-
由 Matthew Wilcox 提交于
Get rid of some unnecessary includes Remove a layer of macro indirection around pdc_console_device Delete pdc_console_die() as it is unused Avoid double-printing on panic by clearing CON_PRINTBUFFER rather than setting con_start to be log_end Make con_start and log_end static again Signed-off-by: NMatthew Wilcox <willy@parisc-linux.org> Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus 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!
-