You can subscribe to this list here.
1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2000 |
Jan
(19) |
Feb
(11) |
Mar
(56) |
Apr
(31) |
May
(37) |
Jun
(21) |
Jul
(30) |
Aug
(31) |
Sep
(25) |
Oct
(60) |
Nov
(28) |
Dec
(57) |
2001 |
Jan
(47) |
Feb
(119) |
Mar
(279) |
Apr
(198) |
May
(336) |
Jun
(201) |
Jul
(136) |
Aug
(123) |
Sep
(123) |
Oct
(185) |
Nov
(66) |
Dec
(97) |
2002 |
Jan
(318) |
Feb
(101) |
Mar
(167) |
Apr
(233) |
May
(249) |
Jun
(134) |
Jul
(195) |
Aug
(99) |
Sep
(278) |
Oct
(435) |
Nov
(326) |
Dec
(325) |
2003 |
Jan
(214) |
Feb
(309) |
Mar
(142) |
Apr
(141) |
May
(210) |
Jun
(86) |
Jul
(133) |
Aug
(218) |
Sep
(315) |
Oct
(152) |
Nov
(162) |
Dec
(288) |
2004 |
Jan
(277) |
Feb
(267) |
Mar
(182) |
Apr
(168) |
May
(254) |
Jun
(131) |
Jul
(168) |
Aug
(177) |
Sep
(262) |
Oct
(309) |
Nov
(262) |
Dec
(255) |
2005 |
Jan
(258) |
Feb
(169) |
Mar
(282) |
Apr
(208) |
May
(262) |
Jun
(187) |
Jul
(207) |
Aug
(171) |
Sep
(283) |
Oct
(216) |
Nov
(307) |
Dec
(107) |
2006 |
Jan
(207) |
Feb
(82) |
Mar
(192) |
Apr
(165) |
May
(121) |
Jun
(108) |
Jul
(120) |
Aug
(126) |
Sep
(101) |
Oct
(216) |
Nov
(95) |
Dec
(125) |
2007 |
Jan
(176) |
Feb
(117) |
Mar
(240) |
Apr
(120) |
May
(81) |
Jun
(82) |
Jul
(62) |
Aug
(120) |
Sep
(103) |
Oct
(109) |
Nov
(181) |
Dec
(87) |
2008 |
Jan
(145) |
Feb
(69) |
Mar
(31) |
Apr
(98) |
May
(91) |
Jun
(43) |
Jul
(68) |
Aug
(135) |
Sep
(48) |
Oct
(18) |
Nov
(29) |
Dec
(16) |
2009 |
Jan
(26) |
Feb
(15) |
Mar
(83) |
Apr
(39) |
May
(23) |
Jun
(35) |
Jul
(11) |
Aug
(3) |
Sep
(11) |
Oct
(2) |
Nov
(28) |
Dec
(8) |
2010 |
Jan
(4) |
Feb
(40) |
Mar
(4) |
Apr
(46) |
May
(35) |
Jun
(46) |
Jul
(10) |
Aug
(4) |
Sep
(50) |
Oct
(70) |
Nov
(31) |
Dec
(24) |
2011 |
Jan
(17) |
Feb
(8) |
Mar
(35) |
Apr
(50) |
May
(75) |
Jun
(55) |
Jul
(72) |
Aug
(272) |
Sep
(10) |
Oct
(9) |
Nov
(11) |
Dec
(15) |
2012 |
Jan
(36) |
Feb
(49) |
Mar
(54) |
Apr
(47) |
May
(8) |
Jun
(82) |
Jul
(20) |
Aug
(50) |
Sep
(51) |
Oct
(20) |
Nov
(10) |
Dec
(25) |
2013 |
Jan
(34) |
Feb
(4) |
Mar
(24) |
Apr
(40) |
May
(101) |
Jun
(30) |
Jul
(55) |
Aug
(84) |
Sep
(53) |
Oct
(49) |
Nov
(61) |
Dec
(36) |
2014 |
Jan
(26) |
Feb
(22) |
Mar
(30) |
Apr
(4) |
May
(43) |
Jun
(33) |
Jul
(44) |
Aug
(61) |
Sep
(46) |
Oct
(154) |
Nov
(16) |
Dec
(12) |
2015 |
Jan
(18) |
Feb
(2) |
Mar
(122) |
Apr
(23) |
May
(56) |
Jun
(29) |
Jul
(35) |
Aug
(15) |
Sep
|
Oct
(45) |
Nov
(94) |
Dec
(38) |
2016 |
Jan
(50) |
Feb
(39) |
Mar
(39) |
Apr
(1) |
May
(14) |
Jun
(12) |
Jul
(19) |
Aug
(12) |
Sep
(9) |
Oct
(1) |
Nov
(13) |
Dec
(7) |
2017 |
Jan
(6) |
Feb
(1) |
Mar
(16) |
Apr
(5) |
May
(61) |
Jun
(18) |
Jul
(43) |
Aug
(1) |
Sep
(8) |
Oct
(25) |
Nov
(30) |
Dec
(6) |
2018 |
Jan
(5) |
Feb
(2) |
Mar
(25) |
Apr
(15) |
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jeff D. <jd...@ka...> - 2001-05-11 01:27:18
|
lis...@os... said: > Either my cvs refreshes aren't working (and I think they are) or > you're not updating the extraversion any more. I sometimes forget. I remembered on this one, so it's 2.4.4-2um. Jeff |
From: <lis...@os...> - 2001-05-11 01:16:13
|
Jeff Dike writes: > This batch merges most of Chris Emerson's ppc changes. > > It also fixes a stupid bug in the last batch which broke the slip backend. > Either my cvs refreshes aren't working (and I think they are) or you're not updating the extraversion any more. Like kernels, I like to have separate binaries for each version. |
From: James S. <mi...@st...> - 2001-05-11 00:54:59
|
Hi sorry this turned out to be a complete hoax it seems that i did a cvs update at the same time jdike was doing the commits and i only got half the updates it now seems to build cleany. thanks James |
From: Chris E. <cem...@ch...> - 2001-05-11 00:46:08
|
On Thursday, 10 May 2001, Jeff Dike wrote: > This batch merges most of Chris Emerson's ppc changes. And the remaining differences from my tree are at http://www.tartarus.org/~chris/user-mode-linux/umlppc-20010511.diff.gz (including some bonus debugging printk()s.) A subset of the above I believe is safe to commit if it's convenient: http://www.tartarus.org/~chris/user-mode-linux/umlppc-20010511-safe.diff.gz Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: James S. <mi...@st...> - 2001-05-10 23:52:57
|
Hi i was working off a clean 2.4.4 tree eg tar xzfvp linux-2.4.4.tar.gz tar cv umlcvstuff tar xv umlstuff cp oldmake make menuconfig make dep make linux On Thu, 10 May 2001, Mooneer Salem wrote: > Try 'make mrproper ARCH=um' then do the entire make config/dep/linux thing > from > the beginning. This happens to me sometimes when I try to recompile > UML after making code changes. > > -----Original Message----- > From: use...@li... > [mailto:use...@li...]On Behalf Of > James Stevenson > Sent: Thursday, May 10, 2001 12:27 PM > To: Jeff Dike > Cc: use...@li... > Subject: Re: [uml-devel] lastest cvs build error > > > > Hi > > nope i did not change anything becaus ei dont understand it enough > it worked until the cvs update you did yester day. > > the cvs on the 1st May worked > now it doesnt > > On Thu, 10 May 2001, Jeff Dike wrote: > > > mi...@st... said: > > > /usr/bin/ld: linux: Not enough room for program headers (allocated 3, > need 4) > > > /usr/bin/ld: final link failed: Bad value > > > collect2: ld returned 1 exit status > > > make: *** [linux] Error 1 > > > > > -- --------------------------------------------- Check Out: http://stev.org E-Mail: mi...@st... 12:50am up 8 days, 8:46, 5 users, load average: 1.22, 1.33, 0.64 |
From: Mooneer S. <mo...@ea...> - 2001-05-10 22:20:40
|
Try 'make mrproper ARCH=um' then do the entire make config/dep/linux thing from the beginning. This happens to me sometimes when I try to recompile UML after making code changes. -----Original Message----- From: use...@li... [mailto:use...@li...]On Behalf Of James Stevenson Sent: Thursday, May 10, 2001 12:27 PM To: Jeff Dike Cc: use...@li... Subject: Re: [uml-devel] lastest cvs build error Hi nope i did not change anything becaus ei dont understand it enough it worked until the cvs update you did yester day. the cvs on the 1st May worked now it doesnt On Thu, 10 May 2001, Jeff Dike wrote: > mi...@st... said: > > /usr/bin/ld: linux: Not enough room for program headers (allocated 3, need 4) > > /usr/bin/ld: final link failed: Bad value > > collect2: ld returned 1 exit status > > make: *** [linux] Error 1 > > I hate it when this happens. Did you change anything from the last successful > build you did (linker, compiler, distro, etc)? Because I haven't changed > anything in link.ld.in lately. > > What you might do is start backing out changes to link.ld.in until you get a > good build. That will tell us what triggered this. > > Every once in a while, after fiddling link.ld.in, I get this. The error > message itself is impenetrable, there are no hints in the docs about what > might be happening, and the code around the error is not helpful. So, I have > no clue what it's complaining about or how to fix it. > > Jeff > > |
From: Jeff D. <jd...@ka...> - 2001-05-10 21:53:46
|
This batch merges most of Chris Emerson's ppc changes. It also fixes a stupid bug in the last batch which broke the slip backend. Jeff |
From: James S. <mi...@st...> - 2001-05-10 18:58:05
|
Hi nope i did not change anything becaus ei dont understand it enough it worked until the cvs update you did yester day. the cvs on the 1st May worked now it doesnt On Thu, 10 May 2001, Jeff Dike wrote: > mi...@st... said: > > /usr/bin/ld: linux: Not enough room for program headers (allocated 3, need 4) > > /usr/bin/ld: final link failed: Bad value > > collect2: ld returned 1 exit status > > make: *** [linux] Error 1 > > I hate it when this happens. Did you change anything from the last successful > build you did (linker, compiler, distro, etc)? Because I haven't changed > anything in link.ld.in lately. > > What you might do is start backing out changes to link.ld.in until you get a > good build. That will tell us what triggered this. > > Every once in a while, after fiddling link.ld.in, I get this. The error > message itself is impenetrable, there are no hints in the docs about what > might be happening, and the code around the error is not helpful. So, I have > no clue what it's complaining about or how to fix it. > > Jeff > > -- --------------------------------------------- Check Out: http://stev.org E-Mail: mi...@st... 7:20pm up 8 days, 3:16, 5 users, load average: 41.12, 42.51, 23.86 |
From: <pau...@gr...> - 2001-05-10 18:29:04
|
On Thu, 10 May 2001, Jeff Dike wrote: > Date: Thu, 10 May 2001 14:17:00 -0500 > From: Jeff Dike <jd...@ka...> > To: pau...@gr... > Cc: use...@li... > Subject: Re: [uml-devel] easy wishlist item > > pau...@gr... said: > > How about including the .config from the kernel build in the binary > > package? > > The question is where. It can't be the root filesystem. The only other > reasonable possibility that I can think of would be something like > /var/lib/uml. > > Jeff I mean just include it in any tarball, rpm or deb package wherever you would normally put readme, changelog, howto, etc. files So in a debian package it would go in /usr/share/doc/<packagename> pw |
From: Jeff D. <jd...@ka...> - 2001-05-10 18:05:03
|
mi...@st... said: > /usr/bin/ld: linux: Not enough room for program headers (allocated 3, need 4) > /usr/bin/ld: final link failed: Bad value > collect2: ld returned 1 exit status > make: *** [linux] Error 1 I hate it when this happens. Did you change anything from the last successful build you did (linker, compiler, distro, etc)? Because I haven't changed anything in link.ld.in lately. What you might do is start backing out changes to link.ld.in until you get a good build. That will tell us what triggered this. Every once in a while, after fiddling link.ld.in, I get this. The error message itself is impenetrable, there are no hints in the docs about what might be happening, and the code around the error is not helpful. So, I have no clue what it's complaining about or how to fix it. Jeff |
From: Jeff D. <jd...@ka...> - 2001-05-10 18:04:14
|
pau...@gr... said: > How about including the .config from the kernel build in the binary > package? The question is where. It can't be the root filesystem. The only other reasonable possibility that I can think of would be something like /var/lib/uml. Jeff |
From: James S. <mi...@st...> - 2001-05-10 15:41:56
|
ld -r init/main.o init/version.o \ --start-group \ kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o \ net/network.o \ /home/mistral/dev/kernel/linux-2.4.4-um-05-10/lib/lib.a /home/mistral/dev/kernel/linux-2.4.4-um-05-10/arch/um/fs/fs.o /home/mistral/dev/kernel/linux-2.4.4-um-05-10/arch/um/kernel/um.o /home/mistral/dev/kernel/linux-2.4.4-um-05-10/arch/um/drivers/um_drivers.o /home/mistral/dev/kernel/linux-2.4.4-um-05-10/arch/um/sys-i386/sys.o /home/mistral/dev/kernel/linux-2.4.4-um-05-10/arch/um/ptproxy/ptproxy.a \ --end-group \ -o vmlinux nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map mv vmlinux vmlinux.o gcc -Wl,-T,/home/mistral/dev/kernel/linux-2.4.4-um-05-10/arch/um/link.ld -o linux -static \ /home/mistral/dev/kernel/linux-2.4.4-um-05-10/arch/um/main.o vmlinux.o -L/usr/lib /usr/bin/ld: linux: Not enough room for program headers (allocated 3, need 4) /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make: *** [linux] Error 1 -- --------------------------------------------- Check Out: http://stev.org E-Mail: mi...@st... 4:40pm up 8 days, 36 min, 5 users, load average: 0.65, 0.69, 0.91 |
From: <pau...@gr...> - 2001-05-10 15:21:26
|
Jeff, How about including the .config from the kernel build in the binary package? Debian places a renamed(e.g. config-2.2.19-ide) copy in the /boot directory when installing a kernel-image package. They also include a copy named kernel-config with the install disk images. This type of thing is so very handy for someone who wants to know how the kernel was built and maybe wants to build one with only a slight difference. pw |
From: Jeff D. <jd...@ka...> - 2001-05-10 15:09:27
|
cem...@ch... said: > I think the sensible thing to do is to move the old_mmap entry in > sys_call_table into ARCH_SYSCALLS. i386 can then replace it with a > wrapper which extracts parameters appropriately. The same will need > to be done to old_select() by the looks of it. Jeff, do you think > there's a better way? That looks like the right thing to do. If a system call signature differs between arches, then it has to become arch-dependent. Jeff |
From: Jeff D. <jd...@ka...> - 2001-05-10 15:05:54
|
ma...@pl... said: > If the ethertap driver is considered obsolete, why are we using it? Because it's not obsolete on 2.2. Jeff |
From: Mark B. <ma...@pl...> - 2001-05-10 14:52:27
|
While I like the idea of an easier to use bridge between UML and the host Linux, I wonder why use the Ethertap driver? According to the Doc..../network/ethertap.txt file with the 2.4.4 kernel: NOTE: Ethertap is now an obsolete facility, and is scheduled to be removed in the 2.5.x kernel series. Those writing applications using ethertap should convert their code to use the TUN/TAP driver instead, see 'tuntap.txt' in this directory for more details. -DaveM If the ethertap driver is considered obsolete, why are we using it? Mark Jeff Dike wrote: > > I've checked in the ethertap backend for the network driver. To use it, you > need to configure both CONFIG_NET_UMN and CONFIG_NET_UM_ETH. You also need > ethertap_helper, which is in /tools/net/ethertap_helper.c. Compile it, make > it suid root, and stick it someplace in your path. > > Run UML with 'ethertap=<interface>,<tap address>,<UML address>' on the kernel > command line. I've been using 'ethertap=tap0,192.168.0.251,192.168.0.252'. > The tap address is the address of the tap device on the host, and UML address > is the eth0 address inside UML. > > I've been ifconfiging as follows: > ifconfig eth0 192.168.0.252 hw ether fe:fd:0:0:0:0 up > > The helper does all the setup on the host, except that ethertap needs to be in > the kernel already. Ultimately, I intend to merge all of the suid helping > into a single helper, which will do everything possible to set things up on > the host. I hope this will eliminate the setup nightmares that people have > with UML networking. > > One thing I've been unable to do is communicate with the outside net through > the tap device. I've tried all the arp and routing tricks I know, but the > other machine can't reach it, or vice versa. The other box arps it fine, but > pings just get dropped. Packet forwarding is on. If anyone knows of anything > I might have missed, let me know. > > Also in this batch is the removal of thread.starting_exec, which is no longer > necessary, and was causing hangs for mistral, although he thinks it's still > happening with an earlier version of this fix. We'll see... > > Jeff > > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > http://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel -- ========================================================================== Mark Buckaway Tel: 416-203-4582 http://www.platespin.com Sr. Software Developer Fax: 416-203-0621 Email: ma...@pl... Platespin Inc. Reception: 416-203-6565 -------------------------------------------------------------------------- The statements made in this message are the opinions of the author and may or may not reflect the opinions of Platespin Inc. -------------------------------------------------------------------------- |
From: Chris E. <cem...@ch...> - 2001-05-10 14:10:44
|
On Thursday, 10 May 2001, Jeff Dike wrote: > cem...@ch... said: > > A quick test using a Debian root disk gets a Kernel mode fault during > > a read(). > > This might be copy_from_user messing up. Could be. I'll look into it at some point. > > Because as it was, in sys_newuname(struct new_utsname *name), name > > was pointing to the sys_pt_regs rather than the user-allocated > > buffer. I can only presume that it works on i386 because function > > arguments are passed on the stack anyway. > > OK, something in there might need to move into arch-specific code. > If we let the arch define sys_call_handler_t and the actual > invocation of the system call, that ought to do it. Why do you want to pass the struct sys_pt_regs through like that, even on i386? I'm slightly surprised it works as it is, but then I may be missing something. > > Fair enough. When's it going to change? :-) > > Probably soon. The problem on i386 is the 2G user/2G kernel option. > That makes TASK_SIZE 0x80000000 rather than 0xc0000000. Is the > process stack at the top of the address space on ppc? What I'm > thinking of doing is rounding the sp up to the nearest 256M and > using that as TASK_SIZE. It's a bit icky, but I think it would work. Linux clearly needs a proper configure script. ;-) Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Jeff D. <jd...@ka...> - 2001-05-10 14:05:07
|
cem...@ch... said: > A quick test using a Debian root disk gets a Kernel mode fault during > a read(). This might be copy_from_user messing up. > Because as it was, in sys_newuname(struct new_utsname *name), name was > pointing to the sys_pt_regs rather than the user-allocated buffer. I > can only presume that it works on i386 because function arguments are > passed on the stack anyway. OK, something in there might need to move into arch-specific code. If we let the arch define sys_call_handler_t and the actual invocation of the system call, that ought to do it. > Fair enough. When's it going to change? :-) Probably soon. The problem on i386 is the 2G user/2G kernel option. That makes TASK_SIZE 0x80000000 rather than 0xc0000000. Is the process stack at the top of the address space on ppc? What I'm thinking of doing is rounding the sp up to the nearest 256M and using that as TASK_SIZE. Jeff |
From: Chris E. <cem...@ch...> - 2001-05-10 13:50:39
|
I've been trying to run dynamically linked binaries under PPC, and found that mmap() doesn't yet work. The first problem is that the signature of old_mmap() has a different signature on i386 due to an old limitation on the numer of syscall arguments (see comment in syscall_kern.c). I think the sensible thing to do is to move the old_mmap entry in sys_call_table into ARCH_SYSCALLS. i386 can then replace it with a wrapper which extracts parameters appropriately. The same will need to be done to old_select() by the looks of it. Jeff, do you think there's a better way? The second problem with mmap() I'm still working on. It's reporting "kernel BUG at memory.c:370". I think I'm going to have to step through an x86 UML and compare what happens. Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: Jeff D. <jd...@ka...> - 2001-05-10 13:22:33
|
joa...@lu... said: > Is it possible to move the mailing lists from Geocrawler to > Sourceforge? They supposedly are. SF uses geocrawler as its list host, I guess. Jeff |
From: Jeff D. <jd...@ka...> - 2001-05-10 13:21:48
|
vi...@ve... said: > I'm wondering what is involved in porting UML to different > architectures; I'm specifically thinking S/390. The best thing to do is to look at the ppc patch, which, coincidentally, is starting to work: http://www.tartarus.org/~chris/user-mode-linux/umlppc-2001051 0.diff.gz It's not very big, and a lot of it is portability fixes in supposedly generic code which the second (or third, if i386 is the first) port won't have to worry about. The first thing to do is to get it to more-or-less compile, which will involve fiddling with the headers. You have a bunch of macros to define, mostly register access macros, and a few procedures (five or so, I think) to define. And then you boot it. Jeff |
From: Vic C. <vi...@ve...> - 2001-05-10 12:27:48
|
Hello folks! I'm new to UML (please don't hold that against me). I'm wondering what is involved in porting UML to different architectures; I'm specifically thinking S/390. I'm not what you'd call a kernel hacker, but have good C skills -- and a desire to 'scratch an itch'. If there's not *too* much work involved, I'm willing to have a go, but I'd like to know where to start... Any assistance would be greatly appreciated -- pointers to doco, etc. Cheers, Vic Cross |
From: Joakim T. <joa...@lu...> - 2001-05-10 10:44:32
|
Hi there Is it possible to move the mailing lists from Geocrawler to Sourceforge? Geocrawler is down several hours every day for "nightly database maintenance". It has been like this since I started to monitor UML a few weeks ago. Jocke |
From: Chris E. <cem...@ch...> - 2001-05-10 08:41:06
|
On Wednesday, 9 May 2001, Jeff Dike wrote: > cem...@ch... said: > > I've finally convinced UML to run user-level code and some system > > calls on PPC. > > W00T!! > > How far does it manage to get? Has it been through any of the tricky system > calls (fork, vfork, exec)? Delivered any process signals? A system call trace lists: uname, geteuid, getuid, getegid, getgid, brk*4, getpid, rt_sigaction, getpid, geteuid, getcwd, ioctl (which returns ENOTTY), more get*id, and read. At that point I get "Kernel panic: Attempted to kill init!" as it calls exit (presumably from EOF on stdin). So no, none of the tricky ones yet, unless you count the initial exec, and no signals. A quick test using a Debian root disk gets a Kernel mode fault during a read(). > > Jeff, if I split out the more dubious bits, can you commit the > > rest to CVS at some point? > > Yeah, I'll pull out the portablility fixes first, get them into CVS, > and send them on to Alan. Excellent. > > I've had to change syscall_handler_t to take 5 long arguments rather > > than a (struct sys_pt_regs). I _think_ my version should be portable > > and seems nicer. > > I don't like this one. Why did you have to do that? Because as it was, in sys_newuname(struct new_utsname *name), name was pointing to the sys_pt_regs rather than the user-allocated buffer. I can only presume that it works on i386 because function arguments are passed on the stack anyway. > > On PPC, TASK_SIZE has to be 0x80000000 instead of 0xc0000000. > > This is wrong even on i386, so it's going to change anyway. Fair enough. When's it going to change? :-) > > PPC and i386 disagree on the type passed to __[u]delay(). I've > > added a typedef (currently called um_udelay_t). > > Did you notice that __delay, __udelay, and __const_udelay are all > wrong? They all take some period of time as an argument and they > all ignore it. Oops. Oh, yeah. Doh. Although it probably doesn't make all that much difference in UML unless there are some more hardwareish drivers. > I'll have to think about the other ones. *nods* > What's > +#include "asm/delay.h" > in arch/um/kernel/um_arch.c for? For loops_per_jiffy, which is declared in asm-ppc/delay.h. > On the whole, this looks fairly reasonable. Phew! :-) Cheers, Chris -- Chris Emerson, obsessed Cambridge juggler E-mail: cem...@ch... Web page: http://www.chiark.greenend.org.uk/~cemerson/ |
From: <lis...@os...> - 2001-05-10 02:53:47
|