On Friday 18 February 2005 02:21, Chuck Berg wrote:
> I have a system with two USB DVD burners. If I burn a disc on both at the
> same time, one of the dvdrecord processes hangs (unkillably stuck in the
> D state). The usb-storage kernel thread was also stuck in the D state.
>
> I power-cycled bot
On Thursday 03 February 2005 06:47, Shane Hathaway wrote:
> The attached patch enhances the kernel's DHCP client support (in
> net/ipv4/ipconfig.c) to set the interface MTU if provided by the DHCP server.
>
> Without this patch, it's difficult to netboot on a network that uses jumbo
> frames.
I found out that I can't strace automount under 2.6.11-rc3:
# strace -p 1002
--- SIGSTOP (Stopped (signal)) ---
--- SIGSTOP (Stopped (signal)) ---
poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = -1 EINTR
(Interrupted system call)
--- SIGALRM (Alarm clock) ---
and strace bails out.
On Tuesday 22 February 2005 13:16, Anthony DiSante wrote:
> Helge Hafting wrote:
> > The infrastructure for that does not exist, so instead, the "killed"
> > process remains. Not all of it, but at least the memory pinned down by
> > the io request. This overhead is typically small, and the overe
On Wednesday 09 March 2005 17:51, Alan Cox wrote:
> On Mer, 2005-03-09 at 07:26, CaT wrote:
> > > Carried over from 2.6.10-ac
> >
> > BTW. What's the probability of the ITE driver making it into the stock
> > kernel?
>
> I have given up caring about the base kernel IDE code. I've tried to get
> s
On Friday 11 March 2005 03:03, Christoph Lameter wrote:
> Changelog:
> - use Kconfig and CONFIG_CLEAR_PAGES
>
> The zeroing of a page of a arbitrary order in page_alloc.c and in hugetlb.c
> may benefit from a
> clear_page that is capable of zeroing multiple pages at once. The following
> patch a
On Friday 11 March 2005 13:08, Simone Piunno wrote:
>
> Hello,
>
> I'm testing a pair of new servers we just bought.
> They are HP DL585 dual Opteron 844 with 8G RAM, RAID1 over 2x72G SCSI disks
> (HP CISS driver) and running 2.6.11. In /proc/driver/cciss/cciss0 we have:
>
> cciss0: HP Smart A
On Saturday 26 March 2005 10:34, Arjan van de Ven wrote:
> On Fri, 2005-03-25 at 17:34 -0500, linux-os wrote:
> > On Fri, 25 Mar 2005, Jesper Juhl wrote:
> >
> > > (please keep me on CC)
> > >
> > >
> > > checking for NULL before calling kfree() is redundant and needlessly
> > > enlarges the kerne
> > It's impossible to be otherwise. A call requires
> > that the return address be written to memory (the stack),
> > using register indirection (the stack-pointer).
>
> and it's a so common pattern that it's optimized to death. Internally a
> call gets transformed to 2 uops or so, one is push ei
I've spent silly amonunt of time trying to use i810 fb on my new spiffy
flat panel. This patch will hopefully help other poor souls.
Patch also fixes module parameter comments.
--
vda
--- linux-2.6.11.src/drivers/video/i810/i810_main.c.orig Thu Mar 3 09:30:58 2005
+++ linux-2.6.11.src/drivers/vid
Try testcase below the sig.
This causes nearly one thousand calls to memcpy in my kernel
(not an allyesconfig one):
# objdump -d vmlinux | grep -F '' | wc -l
959
# gcc -O2 -c t.c
# objdump -r -d t.o
t.o: file format elf32-i386
Disassembly of section .text:
:
0: 55
On Tuesday 29 March 2005 23:22, Denis Vlasenko wrote:
> This patch shortens non-constant memcpy() by two bytes
> and fixes spurious out-of-line constant memcpy().
>
> Patch is run-tested (I run on patched kernel right now).
>
> Benchmark and code generation test program will
This patch shortens non-constant memcpy() by two bytes
and fixes spurious out-of-line constant memcpy().
Patch is run-tested (I run on patched kernel right now).
Benchmark and code generation test program will be mailed as reply.
# size vmlinux.org vmlinux
textdata bss dec hex
On Wednesday 30 March 2005 05:27, Gerold Jury wrote:
>
> >> On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
> >> > /*
> >> > * This looks horribly ugly, but the compiler can optimize it totally,
> >> > * as the count i
On Thursday 31 March 2005 07:38, Robert Hancock wrote:
> Philip Lawatsch wrote:
> > Hi,
> >
> >
> > I do have a very strange problem:
> >
> > If I memset a ~1meg buffer some thousand times (in the userspace) it
> > will hardlock my machine.
>
> I thought that this must be impossible, but I trie
On Thursday 31 March 2005 11:26, Jeff Garzik wrote:
> Yum Rayan wrote:
> > Attempt to reduce stack usage in time.c (linux-2.6.12-rc1-mm3). Stack
> > usage was noted using checkstack.pl. Specifically:
> >
> > Before patch
> >
> > sys_adjtimex - 128
> >
> > After patch
> > ---
On Friday 01 April 2005 11:00, Dave Jones wrote:
:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://w
On Friday 01 April 2005 07:37, Robert Hancock wrote:
> Stelian Pop wrote:
> > Just a thought: does deactivating cpufreq change anything ?
> >
> > I haven't tested yet your program, but on my Asus K8NE-Deluxe very
> > strange things happen if cpufreq/powernow is activated *and*
> > the cpu frequen
On Saturday 02 April 2005 01:08, Richard B. Johnson wrote:
> >> Looking at your other patches, I'm assuming that this is just another
> >> April 1st type of patch. Is it?
> >
> > Arg! I'm too tired. I took another look at your other patches and they
> > look more legit now. On first glance, I thou
> > childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long)
> > p->thread_info)) - 1;
> > *childregs = *regs;
> > ^^^
> > childregs->eax = 0;
> > childregs->esp = esp;
> >
> > # make arch/i386/kernel/process.s
> >
> > copy_thread:
>
On Saturday 02 April 2005 15:18, Denis Vlasenko wrote:
> -O2 compile does inline copying, however, suboptimally.
> Pushing/popping esi/edi on the stack is not needed.
> Also "mov $1,ecx; rep; movsl" is rather silly.
I think I am wrong about push/pop. Sorry.
However, other o
On Friday 21 January 2005 23:41, Matt Mackall wrote:
> Clean up SHA hash function for moving to lib/
> Do proper endian conversion
> Provide sha_init function
> Add kerneldoc
>
> Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
>
> Index: rnd2/drivers/char/random.c
> ==
On Friday 21 January 2005 23:41, Matt Mackall wrote:
> --- rnd2.orig/include/linux/bitops.h 2005-01-19 22:57:54.0 -0800
> +++ rnd2/include/linux/bitops.h 2005-01-20 09:20:24.641660815 -0800
> @@ -134,4 +134,26 @@
> return sizeof(w) == 4 ? generic_hweight32(w) : generic_hweight6
On Friday 21 January 2005 23:41, Matt Mackall wrote:
> - * @W: 80 words of workspace
> + * @W: 80 words of workspace, caller should clear
Why?
> *
> * This function generates a SHA1 digest for a single. Be warned, it
> * does not handle padding and message digest, do not confuse i
On Tuesday 25 January 2005 23:14, Matt Mackall wrote:
> On Tue, Jan 25, 2005 at 11:07:21PM +0200, Denis Vlasenko wrote:
> > On Friday 21 January 2005 23:41, Matt Mackall wrote:
> > > - * @W: 80 words of workspace
> > > + * @W: 80 words of workspace, calle
On Friday 21 January 2005 22:46, Denis Zaitsev wrote:
> The long story is:
>
> There is a Dual-processor Intel Server Board STL2 with two P-III/800
> and an onboard Intel 82557-based ethernet card. The box has all the
> /usr and nearly all of the /var filesystems mounted over NFS. And the
> box
On Sunday 22 July 2007 00:16, Oleg Verych wrote:
> * From: Andi Kleen <[EMAIL PROTECTED]>
> * Date: Thu, 19 Jul 2007 11:54:53 +0200 (CEST)
> >
> > Jan asked to always use the builtin memcpy on gcc 4.3 mainline because
> > it should generate better code than the old macro. Let's try it.
>
> Unfortu
On Thursday 21 June 2007 21:32, Mathieu Desnoyers wrote:
> Let's take arch/i386/boot/video.h as an example:
>
> it defines
>
> struct card_info {
> const char *card_name;
> int (*set_mode)(struct mode_info *mode);
> int (*probe)(void);
> struct mode_info *modes;
>
On 8/8/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> You keep claiming that hrtimers are so incredibly expensive; but for
> msleep()... which is mostly called during driver init ... I really don't
> buy that it's really expensive. We're not doing this a gazilion times
> per second obviously...
On 8/9/07, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> On 8/8/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > You keep claiming that hrtimers are so incredibly expensive; but for
> > msleep()... which is mostly called during driver init ... I really don't
&g
Hi Satyam,
On Monday 23 July 2007 17:05, Satyam Sharma wrote:
> There was a lot of bogus stuff that include/asm-i386/bitops.h was doing,
> that was unnecessary and not required for the correctness of those APIs.
> All that superfluous stuff was also unnecessarily disallowing compiler
> optimizatio
On Wednesday 18 July 2007 22:04, Andi Kleen wrote:
> Better just write less bloated code. Perhaps mandatory bloatometer
> runs during -rc*s for kernels with minimal config with public code pig shame
> lists
> similar to the regression lists are useful. Anyone volunteering?
>
> I suspect there is a
Hi,
Attached patch deinlines and moves big functions from .h to .c files
in drivers/scsi/aic7xxx/*. I also had to add prototypes for ahc_lookup_scb
and ahd_lookup_scb to .h files.
No other code changes made.
Compile-tested on i386 and x86-64.
Total .text size reduction: ~60k in 64 bits, ~90k in
On 8/2/07, Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> > > Please, copy strtonum() from BSD instead. Nobody needs another
> > > home-grown converter.
> >
> > BSD's strtonum(3) is a detestful, horrible shame.
> >
> > The strtol_check_range() I implemented here does _all_ that strtonum()
> > does, p
On Thursday 11 January 2007 16:50, Linus Torvalds wrote:
>
> On Thu, 11 Jan 2007, Nick Piggin wrote:
> >
> > Speaking of which, why did we obsolete raw devices? And/or why not just
> > go with a minimal O_DIRECT on block device support? Not a rhetorical
> > question -- I wasn't involved in the di
On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> example, which isn't quite possible now from userspace. But as long as
> O_DIRECT actually writes data before returning from write() call (as it
> seems to be the case at least with a normal filesystem on a real block
> device - I don't t
On Sunday 14 January 2007 10:11, Nate Diller wrote:
> On 1/12/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Most applications don't get the kind of performance analysis that
> Digeo was doing, and even then, it's rather lucky that we caught that.
> So I personally think it'd be best for libc or s
On Saturday 20 January 2007 21:55, Michael Tokarev wrote:
> Denis Vlasenko wrote:
> > On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> >> example, which isn't quite possible now from userspace. But as long as
> >> O_DIRECT actually writes data before re
On Sunday 21 January 2007 13:09, Michael Tokarev wrote:
> Denis Vlasenko wrote:
> > On Saturday 20 January 2007 21:55, Michael Tokarev wrote:
> >> Denis Vlasenko wrote:
> >>> On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> >>>> example,
On Monday 22 January 2007 17:17, Phillip Susi wrote:
> > You do not need to know which read() exactly failed due to bad disk.
> > Filename and offset from the start is enough. Right?
> >
> > So, SIGIO/SIGBUS can provide that, and if your handler is of
> > void (*sa_sigaction)(int, siginfo_t *,
On Thursday 25 January 2007 16:44, Phillip Susi wrote:
> Denis Vlasenko wrote:
> > I will still disagree on this point (on point "use O_DIRECT, it's faster").
> > There is no reason why O_DIRECT should be faster than "normal" read/write
> > to l
On Thursday 25 January 2007 20:28, Phillip Susi wrote:
> > Ahhh shit, are you saying that fdatasync will wait until writes
> > *by all other processes* to thios file will hit the disk?
> > Is that thue?
>
> I think all processes yes, but certainly all writes to this file by this
> process. That
On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> Phillip Susi wrote:
> > Denis Vlasenko wrote:
> >> You mean "You can use aio_write" ?
> >
> > Exactly. You generally don't use O_DIRECT without aio. Combining the
> > two is w
On Wednesday 27 December 2006 00:55, David Lang wrote:
> On Tue, 26 Dec 2006, Rob Landley wrote:
>
> > I'm trying to make some nommu-friendly busybox-like tools, which means using
> > vfork() instead of fork(). This means that after I fork I have to exec in
> > the child to unblock the parent, an
On Wednesday 27 December 2006 06:13, Ray Lee wrote:
> On 12/26/06, Rob Landley <[EMAIL PROTECTED]> wrote:
> > I'm trying to make some nommu-friendly busybox-like tools, which means using
> > vfork() instead of fork(). This means that after I fork I have to exec in
> > the child to unblock the pare
On Wednesday 27 December 2006 22:03, Rob Landley wrote:
> On Wednesday 27 December 2006 1:35 pm, Denis Vlasenko wrote:
> > This solves chroot problem. How to find path-to-yourself reliably
> > (for one, without using /proc/self/exe) is not obvious to me.
>
> Been there, done
On Friday 29 December 2006 07:16, Robert P. J. Day wrote:
>
> is there some reason there are so many calls of the form
>
> memset(addr, 0, PAGE_SIZE)
>
> rather than the apparently equivalent invocation of
>
> clear_page(addr)
>
> the majority of architectures appear to define the clear_
On Tuesday 26 December 2006 16:18, Tejun Heo wrote:
> Hello, all.
>
> This patchset implements managed device resources, in short, devres.
I was working on a Linux device driver. Indeed, those error paths
are notoriously prone to bugs.
Patchset looks like good idea to me.
--
vda
-
To unsubscribe
On Saturday 30 December 2006 23:08, Robert P. J. Day wrote:
> >
> > clear_page assumes that given address is page aligned, I think. It
> > may fail if you feed it with misaligned region's address.
>
> i don't see how that can be true, given that most of the definitions
> of the clear_page() macro
On Wednesday 03 January 2007 17:03, Linus Torvalds wrote:
> On Wed, 3 Jan 2007, Grzegorz Kulewski wrote:
> > Could you explain why CMOV is pointless now? Are there any benchmarks
> > proving
> > that?
>
> CMOV (and, more generically, any "predicated instruction") tends to
> generally a bad idea
On Wednesday 03 January 2007 21:38, Linus Torvalds wrote:
> On Wed, 3 Jan 2007, Denis Vlasenko wrote:
> >
> > Why CPU people do not internally convert cmov into jmp,mov pair?
>
...
> It really all boils down to: there's simply no real reason to use cmov.
> It'
On Friday 26 January 2007 18:05, Phillip Susi wrote:
> Denis Vlasenko wrote:
> > Which shouldn't be true. There is no fundamental reason why
> > ordinary writes should be slower than O_DIRECT.
>
> Again, there IS a reason: O_DIRECT eliminates the cpu overhead of the
On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> >> Phillip Susi wrote:
> >>> Denis Vlasenko wrote:
> >>>> You mean "You can use aio_write" ?
>
On Saturday 27 January 2007 15:01, Bodo Eggert wrote:
> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> > On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> >> Denis Vlasenko wrote:
> >> > On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
>
>
Hi,
I am currently on Linux 2.6.18, x86_64.
I came across strange behavior while working on one
of busybox applets. I narrowed it down to these two
trivial testcases:
#include
#include
int main() {
fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
return 0;
}
#include
#inc
On Sunday 28 January 2007 16:18, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> >> Denis Vlasenko wrote:
> >>> On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> >>>> Phillip Susi wrot
On Sunday 28 January 2007 16:30, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Saturday 27 January 2007 15:01, Bodo Eggert wrote:
> >> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> >>> On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> >>&g
On Monday 29 January 2007 18:00, Andrea Arcangeli wrote:
> On Sun, Jan 28, 2007 at 06:03:08PM +0100, Denis Vlasenko wrote:
> > I still don't see much difference between O_SYNC and O_DIRECT write
> > semantic.
>
> O_DIRECT is about avoiding the copy_user between cache an
On Tuesday 30 January 2007 04:40, Philippe Troin wrote:
> > int main() {
> > fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
> > return 0;
> > }
> >
> > int main() {
> > fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) & ~O_NONBLOCK);
> > return 0;
> > }
> >
> > If I r
On Sunday 04 February 2007 01:55, David Schwartz wrote:
>
> > That's a bug, right? I couldn't find anything to that effect in IEEE
> > Std. 1003.1, 2004 Edition...
> >
> > Ciao,
> > Roland
>
> It's not a bug, there's no rational alternative. What would two indepedent
> file d
On Saturday 16 December 2006 10:07, Marek Wawrzyczny wrote:
> The open source driver development is promising but it has been mentioned
> several times that the project is undermanned and the vendors are not
> forthcoming with the necessary information.
> My hardware as it stands today is still n
On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
> Hugh Dickins wrote:
> In many cases the use of O_DIRECT is purely to avoid impact on cache
> used by other applications. An application which writes a large quantity
> of data will have less impact on other applications by using O_DIRECT,
On Friday 05 January 2007 17:20, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > But O_DIRECT is _not_ about cache. At least I think it was not about
> > cache initially, it was more about DMAing data directly from/to
> > application address space to/from disks, savin
On Thursday 04 January 2007 18:37, Linus Torvalds wrote:
> With 7+ million lines of C code and headers, I'm not interested in
> compilers that read the letter of the law. We don't want some really
> clever code generation that gets us .5% on some unrealistic load. We want
> good _solid_ code gen
On Thursday 11 January 2007 02:02, Neil Brown wrote:
> If regs->rax is unsigned long, then I would think the compiler would
> be allowed to convert
>
>switch (regs->rax) {
> case -514 : whatever;
>}
>
> to a no-op, as regs->rax will never have a negative value.
In C, you never actu
On Thursday 28 December 2006 10:06, Benny Halevy wrote:
> Mikulas Patocka wrote:
> >>> If user (or script) doesn't specify that flag, it doesn't help. I think
> >>> the best solution for these filesystems would be either to add new syscall
> >>> int is_hardlink(char *filename1, char *filename2)
>
On Wednesday 03 January 2007 13:42, Pavel Machek wrote:
> I guess that is the way to go. samefile(path1, path2) is unfortunately
> inherently racy.
Not a problem in practice. You don't expect cp -a
to reliably copy a tree which something else is modifying
at the same time.
Thus we assume that the
On Wednesday 03 January 2007 21:26, Frank van Maarseveen wrote:
> On Wed, Jan 03, 2007 at 08:31:32PM +0100, Mikulas Patocka wrote:
> > 64-bit inode numbers space is not yet implemented on Linux --- the problem
> > is that if you return ino >= 2^32, programs compiled without
> > -D_FILE_OFFSET_BIT
On Saturday 21 October 2006 20:08, Ben Greear wrote:
> > > or shouldn't rpm notice the previous process is dead and
> > > clean it up itself?
> >
> > Sounds sensible to me and you, but in the past sensible ideas and
> > rpm maintainers haven't gone hand in hand.
> >
> Ahhh :)
Well said. rpm
On Sunday 10 June 2007 20:58, Rene Herman wrote:
> All that stuff only serves to multiply the speed at which a fixed percentage
> of content obsoletes itself. When it's still new and shiny, sure, stuff will
> get translated but in no time at all it'll become a fragmented mess which
> nobody ever
On Monday 11 June 2007 02:56, Paul Mundt wrote:
> On Mon, Jun 11, 2007 at 01:59:00AM +0200, Denis Vlasenko wrote:
> > On Sunday 10 June 2007 20:58, Rene Herman wrote:
> > > All that stuff only serves to multiply the speed at which a fixed
> > > percentage of content
On Friday 06 July 2007 08:35, Jesper Juhl wrote:
> On 06/07/07, Kaleem Khan <[EMAIL PROTECTED]> wrote:
> > Hello Kernel experts,
> >
> > I'd like to know whether there's a way to take some action (say
> > calling a routine) in
> > response to 'kill -9' before the process is terminated. I tend to
>
On Thursday 05 July 2007 21:34, Andrew Morton wrote:
> On Thu, 5 Jul 2007 12:51:52 +0200
> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
>
> > Using code from
> >
> > http://www.cs.uiowa.edu/~jones/bcd/decimal.html
> > (with permission from the author, Douglas
On Thursday 24 May 2007 21:56, Uwe Bugla wrote:
> Please note:
>
> 1. IRQ 255 looks very idiotic, doesn't it? It does not exist at all, does it?
>
> Questions:
>
> 1. What is the technical need / progress of module ssb please?
>
> 2. If Andrew Morton's guidelines clearly say: "Do test your patc
On Tuesday 17 July 2007 00:42, Bodo Eggert wrote:
> > Please note that I was not trying to remove the 8K stack option right
> > now - heck, I didn't even add anything to feature-removal-schedule.txt
> > - all I wanted to accomplish with the patch that started this threas
> > was; a) indicate that
On Thursday 05 July 2007 01:50, Jesper Juhl wrote:
> > Removes conditional branch from schedule(). Code savings on my
> >usual config:
> >
> >textdata bss dec hex filename
> > 2921871 179895 180224 3281990 321446 vmlinux before
> > 2920141
On Saturday 10 March 2007 13:16, Mockern wrote:
> I have a problem with cat < /dev/my_ttyS0 (see strace output below).
> cat function is not blocked. I don't understand why it is not stopped
> at read(0, __ and terminated?
> Thank you
Because /dev/my_ttyS0 is probaly a null file.
Please show
Hi kernel people,
Just upgraded by home box to 2.6.20.7. Wow.
* Reiser3 mount times are drastically reduced,
even when journal replay is needed
(I have few 100Gb+ reiser3 partitions mounted at boot)
* sit pseudo-interface is gone. In previous kernel, I tried
to disable it in kernel config t
On Saturday 21 April 2007 18:00, Ingo Molnar wrote:
> correct. Note that Willy reniced X back to 0 so it had no relevance on
> his test. Also note that i pointed this change out in the -v4 CFS
> announcement:
>
> || Changes since -v3:
> ||
> || - usability fix: automatic renicing of kernel thre
Hi Tom.
On Thursday 19 April 2007 21:00, Tom Strader wrote:
> This is the final output from my kernel as I try to launch busybox
> (/sbin/init is linked to /bin/busybox)
> As it launches the kernel looks for libraries which do not exist (not
> sure why), but it appears to find /lib/libcrypt.so.1 a
Hi,
On Sunday 18 March 2007 22:06, Robert P. J. Day wrote:
> p.s. just FYI, i ran my "find dead CONFIG variables" script on the
> entire tree and, as we speak, there are 316 preprocessor tests that
> are testing variables of the form "CONFIG_whatever" for which that
> option is not set anywhere i
Theodore Tso wrote:
>
> One of the big problems of using a filesystem as a DB is the system
> call overheads. If you use huge numbers of tiny files, then each
> attempt read an atom of information from the DB takes three system
> calls --- an open(), read(), and close(), with all of the overheads
On Thursday 08 March 2007 18:28, Linus Torvalds wrote:
> The sad part is that there really is no reason why the BSD crowd couldn't
> have done recvmsg() as an "extended read with per-system call flags",
> which would have made things like O_NONBLOCK etc unnecessary, because you
> could do it jus
101 - 183 of 183 matches
Mail list logo
