Hi,
On Tue, 29 Jan 2008, john stultz wrote:
> +/* Because using NSEC_PER_SEC would be too easy */
> +#define NTP_INTERVAL_LENGTH
> s64)TICK_USEC*NSEC_PER_USEC*USER_HZ)+CLOCK_TICK_ADJUST)/NTP_INTERVAL_FREQ)
Why are you using USER_HZ? Did you test this with HZ!=100?
Anyway, please don't make
Hi,
On Wed, 30 Jan 2008, john stultz wrote:
> My concern is we state the accumulation interval is X ns long. Then
> current_tick_length() is to return (X + ntp_adjustment), so each
> accumulation interval we can keep track of the error and adjust our
> interval length.
>
> So if ntp_update_frequ
Hi,
On Mon, 11 Feb 2008, john stultz wrote:
> > I don't want to just send a patch, I want you to understand why your
> > approach is wrong.
>
> With all due respect, it also keeps the critique in one direction and
> makes your review less collaborative and more confrontational then I
> suspect
Hi,
On Wednesday 13. February 2008, Francis Moreau wrote:
> First I tried to find some documentation on the current implementation
> but haven't found any thing really usefull. Specially there's nothing about
> it in Documentation/ directory. Please correct me if I'm already wrong.
>
> Actually I
Hi,
On Wednesday 13. February 2008, Sam Ravnborg wrote:
> config foo
> tristate "do you want foo?"
> depends on USB && BAR
> module
> obj-$(CONFIG_FOO) += foo.o
> foo-y := file1.o file2.o
> help
> foo will allow you to explode your PC
I'm more thin
Hi,
On Wed, 13 Feb 2008, john stultz wrote:
> Oh! So your issue is that since time_freq is stored in ppm, or in effect
> a usecs per sec offset, when we add it to something other then 1 second
> we mis-apply what NTP tells us to. Is that right?
Pretty much everything is centered around that 1sec
Hi,
On Mon, 18 Feb 2008, john stultz wrote:
> If we are building a train station, and each train car is 60ft, it
> doesn't make much sense to build 1000ft stations, right? Instead you'll
> do better if you build a 1020ft station.
That would assume trains are always 60ft long, which is the basic
LOCK_TICK_ADJUST
completely. Add a optional kernel parameter ntp_tick_adj instead to allow
adjusting of a large base drift and thus keeping ntpd happy.
The CLOCK_TICK_ADJUST mechanism was introduced at a time PIT was the
primary clock, but we have a varity of clock sources now, so a global PIT
specific a
Hi,
On Fri, 1 Feb 2008, John Stultz wrote:
> > CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't
> > based on HZ, there is no point in using it!
>
> Hey Roman,
>
> Again, I'm sorry I don't seem to be following your objections. If you
> want to suggest a different patch
Hi,
On Wed, 30 Jan 2008, Miklos Szeredi wrote:
> > How does this deal with certain special cases:
> > - chroot: how will mount/df only show the for chroot relevant mounts?
>
> That is a very good question. Andreas Gruenbacher had some patches
> for fixing behavior of /proc/mounts under a chroot
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
>
> clock = clocksource_get_next();
> - clocksource_calculate_interval(clock,
> - (unsigned long)(current_tick_length()>>TICK_LENGTH_SHIFT));
> + clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
> clock->cycle
Hi,
On Fri, 8 Feb 2008, Andrew Morton wrote:
> > Only now I noticed that the first patch had been merged without any
> > further question. :-(
> > What point is there in reviewing patches, if everything is merged anyway.
> > :-(
> >
>
> oops, mistake, sorry. There's plenty of time to fix it
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
> -ENOPATCH
>
> We're taking weeks to critique fairly small bug fix. I'm sure we both
> have better things to do then continue to misunderstand each other. I'll
> do the testing and will happily ack it if it resolves the issue.
I don't want to just sen
Hi,
On Thu, 21 Feb 2008, john stultz wrote:
> > Again, what kind of crappy hardware do you expect? Aren't clocks supposed
> > to get better and not worse?
>
> Well, while I've seen much worse, I consider crappy hardware to be 100
> +ppm error. So if the hardware is perfect and the system result
Hi,
On Thu, 21 Feb 2008, David Howells wrote:
> The kernel NTP code shouldn't hand 64-bit *signed* values to do_div(). Make
> it
> instead hand 64-bit unsigned values. This gets rid of a couple of warnings.
I would actually prefer to introduce an explicit API for signed 64
divides to get rid
Hi,
Mark Hounschell wrote:
> I'm not a list member so IF you respond to this mail please CC me.
> I've been looking at the archives and see some problems with the 2.3.x
> kernel versions and affs support.
I've put a new version at
http://www.xs4all.nl/~zippel/affs.010414.tar.gz
bye, Roman
-
T
Hi,
Mark Hounschell wrote:
> Thanks, I can now mount affs filesystems. However when I try to write
> to it via "cp somefile /amiga/somefile" I get a segmentation fault. If
> I then do a "df -h" it hangs the system very much like the mount command
> did before I installed your tar-ball. Was write
Hi,
Mark Hounschell wrote:
> Sorry I didn't get back to you yesterday afternoon. I was out of town.
> Attached is the output from dmesg and the relavent info from
> /var/log/messages.
Could you try the attached patch? I forgot to initialize a variable
correctly.
(I also put a new version at
h
Hi,
Alexander Viro wrote:
> unlink("/B/b") locks /B, removes "b" and unlocks /B. Then it calls
> affs_remove_link(), which blocks.
>
> unlink("/A/a") locks /A, removes "a" and unlocks /A. Then it calls
> affs_remove_link(). Which locks /B, renames removed entry into "b",
> removes old "b" and i
Hi,
Jes Sorensen wrote:
> In principle you just need 2.7.2.3 for m68k, but someone decided to
> raise the bar for all architectures by putting a check in a common
> header file.
IIRC 2.7.2.3 has problems with labeled initializers for structures,
which makes 2.7.2.3 unusable for all archs under
Hi,
On Tue, 20 Feb 2001, Neil Brown wrote:
> 2/ lookup("..").
A small question:
Why exactly is this needed?
bye, Roman
-
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/majordo
Hi,
On 20 Feb 2001, Trond Myklebust wrote:
> IIRC several NFS implementations (not Linux though) rely on being able
> to walk back up the directory tree in order to discover the path at
> any given moment.
If I read the source correctly, namespace operation are done with dir file
handle + file
Hi,
On Tue, 20 Feb 2001, Trond Myklebust wrote:
> If I read the code correctly, we set the dentry d_flag
> DCACHE_NFSD_DISCONNECTED on such dummy dentries. We only force a
> lookup of the full path if the inode represents a directory or the
> NFSEXP_NOSUBTREECHECK export flag is not set.
IMO y
Hi,
On Thu, 1 Mar 2001, Alexander Viro wrote:
> +static int generic_vm_expand(struct address_space *mapping, loff_t size)
> +{
> + struct page *page;
> + unsigned long index, offset;
> + int err;
> +
> + if (!mapping->a_ops->prepare_write || !mapping->a_ops->commit_write)
> +
Hi,
On Thu, 1 Mar 2001, Alexander Viro wrote:
> IOW, if it's worth doing at all it probably should be
> on expanding path in vmtruncate() - limit checks are already
> done, but old i_size is still not lost...
The fs where it's important have mmu_private, that's what I use to decide
whethe
Hi,
On Thu, 18 Jan 2001, Andrew Morton wrote:
> - Get rid of the special printk buffer - share the
> log buffer. (Implies writes to console
> devices will be broken into two writes when they
> wrap around).
> - Teach vsprintf to print into a circular buffer
> (snprintf thus comes for fr
Hi,
On Thu, 18 Jan 2001, Linus Torvalds wrote:
> > Actually, this is a great example, because at one point I was working
> > on a device interface which would offload all of the disk-disk copying
> > overhead to the disks themselves, and not involve the CPU/RAM at all.
>
> It's a horrible examp
Hi,
On Thu, 18 Jan 2001, Linus Torvalds wrote:
> It's too damn device-dependent, and it's not worth it. There's no way to
> make it general with any current hardware, and there probably isn't going
> to be for at least another decade or so. And because it's expensive and
> slow to do even on a h
Hi,
On Thu, 18 Jan 2001, Linus Torvalds wrote:
> > I agree, it's device dependent, but such hardware exists.
>
> Show me any practical case where the hardware actually exists.
http://www.augan.com
> I do not know of _any_ disk controllers that let you map the controller
> buffers over PCI. Wh
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
> There's no no-no here: you can even create the "struct page"s on demand,
> and create a dummy local zone that contains them that they all point back
> to. It should be trivial - nobody else cares about those pages or that
> zone anyway.
AFAIK as
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
> But point-to-point also means that you don't get any real advantage from
> doing things like device-to-device DMA. Because the links are
> asynchronous, you need buffers in between them anyway, and there is no
> bandwidth advantage of not going th
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
> Now, there are things to look out for: when you do these kinds of dummy
> "struct page" tricks, some macros etc WILL NOT WORK. In particular, we do
> not currently have a good "page_to_bus/phys()" function. That means that
> anybody trying to do D
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
> But think like a good hardware designer.
>
> In 99% of all cases, where do you want the results of a read to end up?
> Where do you want the contents of a write to come from?
>
> Right. Memory.
>
> Now, optimize for the common case. Make the co
Hi,
Here is a patch for anyone who needs to access HFS on e.g. an MO drive.
It's only for 2.2.16, but I was able to do that as part of my job as we
need that functionality. Anyway, I've read also a bit through HFS+ spec
and IMO basically most of the current hfs needs to rewritten for 2.4,
e.g. it
Hi,
> Darnit, documentation on filesystem locking is there for purpose. First
> folks complain about its absence, then they don't bother to read the
> bloody thing once it is there. Furrfu...
It's great that it's there, but still doesn't tell you everything.
> Said that, handling of indirect bl
Hi,
> > hfs. For example reading from a file might require a read from a btree
> > file (extent file), with what another file write can be busy with (e.g.
> > reordering the btree nodes).
>
> And?
The point is: the thing I like about Linux is its simple interfaces, it's
the basic idea of unix -
Hi,
> Yes? And it will become simpler if you will put each and every locking
> scheme into the API?
No, I didn't say that. I want the API to be less restrictive and make
the job for the fs a bit easier. IMO the current API is inconsistent
and/or incomplete and I'm still trying to find out what e
Hi,
Tony Mantler wrote:
> For those of you who would rather not have read through this entire email,
> here's the condensed version: VFS is inherintly a wrong-level API, QNX does
> it much better. Flame on. :)
VFS isn't really wrong, the problem is that it moved from an almost
single threaded A
Hi,
> It sounds to me like different FSes have different needs. Maybe the best
> approach is to have two or three fs APIs, according to the needs of the
> fs.
No, having several fs API is a maintainance nightmare, I think that's
something everyone agrees on. What is needed is to modify the API
Hi,
> Show me these removed locks. The only polite explanation I see is
> that you have serious reading comprehension problems. Let me say it once
> more, hopefully that will sink in:
>
> Your repeated claims of VFS becoming more multi-threaded in ways
> that are not transparent to f
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Hi,
(Sorry for the previous empty mail, I was a bit too fast with sending and
couldn't stop it completly.)
On Wed, 30 Aug 2000, Alexander Viro wrote:
I concentrate on the most interesting part:
> As for AFFS directory format - fine, please describe the data
> manipulations required by unlink("
Hi,
On Wed, 30 Aug 2000, Alexander Viro wrote:
> c) ->i_sem on pageout? When?
For 2.2.16:
filemap_write_page() <- filemap_swapout() <- try_to_swap_out() <- ... <-
swap_out() <- do_try_to_free_pages() <- kswapd()
filemap_write_page() takes i_sem and calls do_write_page(). What did I
miss
Hi,
> > - get dentry foo
> > - get dentry baz
>
> How? OK, you've found block of baz. You know the name, all right.
Links are chained together and all point back to the original, so if you
remove the original, you have quite something to do with lots of links.
> Now
> you've got to do the full
Hi,
On Thu, 31 Aug 2000, Alexander Viro wrote:
> Go ahead, write it. IMNSHO it's going to be much more complicated and
> race-prone, but code talks. If you will manage to write it in clear and
> race-free way - fine. Frankly, I don't believe that it's doable.
It will be insofar more complicated
Hi,
On Mon, 4 Sep 2000, Alan Cox wrote:
> Then they need more competant admins. It isnt _hard_ to transproxy outgoing
> smtp traffic via a spamtrapper that checks for valid src/destination and
> headers.
You get into a dangerous field here. If you start arguing like this, how
do you explain to
Hi,
On Mon, 18 Dec 2000, Bernardo Innocenti wrote:
> [1.] One line summary of the problem:
> mounting affs over loop hangs in syscall (x86 only?)
affs plays some games with the suberblock lock, I have a patch that plays
even worse games, but it works. I hope to finish a major cleanup of affs
ov
Hi,
On Sun, 31 Dec 2000, Andrea Arcangeli wrote:
> > estimate than just the data blocks it should not be hard to add an
> > extra callback to the filesystem.
>
> Yes, I was thinking at this callback too. Such a callback is nearly the only
> support we need from the filesystem to provide alloc
Hi,
On Sat, 30 Dec 2000, Linus Torvalds wrote:
> In fact, in a properly designed filesystem just a bit of low-level caching
> would easily make the average "get_block()" be very fast indeed. The fact
> that right now ext2 has not been optimized for this is _not_ a reason to
> design the VFS laye
Hi,
On Sun, 31 Dec 2000, Linus Torvalds wrote:
> Let me repeat myself one more time:
>
> I do not believe that "get_block()" is as big of a problem as people make
> it out to be.
The real problem is that get_block() doesn't scale and it's very hard to
do. A recursive per inode-semaphore migh
Hi,
On Sun, 31 Dec 2000, Linus Torvalds wrote:
> cached_allocation = NULL;
>
> repeat:
> spin_lock();
> result = try_to_find_existing();
> if (!result) {
> if (!cached_allocation) {
>
Hi,
On Sun, 31 Dec 2000, Alexander Viro wrote:
> Reread the original thread. GFP_BUFFER protects us from buffer cache
> allocations triggering pageouts. It has nothing to the deadlock scenario
> that would come from grabbing ->i_sem on pageout.
I don't want to grab i_sem. It was a very, very ea
Hi,
On Mon, 1 Jan 2001, Alexander Viro wrote:
> But... But with AFFS you _have_ exclusion between block-allocation and
> truncate(). It has no sparse files, so pageout will never allocate
> anything. I.e. all allocations come from write(2). And both write(2) and
> truncate(2) hold i_sem.
>
> Pr
Hi,
On Tue, 2 Jan 2001, Alexander Viro wrote:
> Depends on a filesystem. Generally you don't want asynchronous operations
> to grab semaphores shared with something else. kswapd knows to skip the locked
> pages, but that's it - if writepage() is going to block on a semaphore you
> will not know
Hi,
On Tue, 2 Jan 2001, David S. Miller wrote:
>We really can't. We _only_ have load-and-zero. And it has to be
>16-byte aligned. xchg() is just not something the CPU implements.
>
> Oh bugger... you do have real problems.
For 2.5 we could move all the atomic functions from atomic.h
Hi,
On Mon, 2 Oct 2000, Andries Brouwer wrote:
> These days I have as background activity the construction
> of the corresponding patch for 2.4. Maybe we can start 2.5
> without these arrays and with large device numbers.
I started something like this a few months ago, I was at the point to boo
Hi,
On Sun, 1 Oct 2000, Andrea Arcangeli wrote:
> Comments?
When that is done, please don't call __sti() directly and use some macro
that can be overridden by the architectures.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
Hi,
On Mon, 2 Oct 2000, Andrea Arcangeli wrote:
> > When that is done, please don't call __sti() directly and use some macro
> > that can be overridden by the architectures.
>
> What do you have in mind while making this suggestion? The irq highlevel layer
> is pretty much architectural indipen
Hi,
A few bss changes (to remove zero initialization) in test9 were not
completly correct. Init data must be initialized if you want that it gets
into the init section (it's also mentioned in the gcc documentation).
The following patch fixes what I was able to find with grep and also adds
a note
Hi,
> The m68k port which has a interrupt stack solves the problem by
> loading current into a global register variable on all kernel entries.
Not all m68k cpus have an interrupt stack and it can be turned off, so we
don't use it.
bye, Roman
-
To unsubscribe from this list: send the line "uns
Hi,
On Wed, 11 Oct 2000, Alan Cox wrote:
> > http://www.osopinion.com/Opinions/MontyManley/MontyManley15.html
> >
> > good article, several unfortunate truths within.
>
> Really, must be a wrong URL you posted then 8)
>
> The average Linux kernel hacker right now is late 20's to early 30's wi
Hi,
> How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
> __builtin_return_address() yields garbage. Does anybody have a generic
> solution to this problem, other than "compile with frame pointers"? Or is
> it fixed in newer versions of gcc?
Are you sure? I just I trie
Hi,
On Fri, 13 Oct 2000, Richard Henderson wrote:
> Either that or adjust how we do atomic operations. I can do
> 64-bit atomic widgetry, but not with the code as written.
It's probably more something for 2.5, but what about adding a lock
argument to the atomic operations, then sparc could use
Hi,
On Sun, 15 Oct 2000, Andi Kleen wrote:
> You can just use the coded out variant (x<>(sizeof(x)*8-n)))
> gcc is clever enough to turn it into an rotate when the CPU supports it.
Hmm, I just tried it and two things one should take care of here. 1. x
must be unsigned of course and 2. only gcc
Hi,
I noticed that behaviour of BLKSSZGET changed between 2.2 and 2.4. One of
the users will be fdisk, as soon as it is compiled with 2.4 kernel
headers, but then fdisk will be no longer usable under 2.2!
My question now is, wouldn't it be better to use a new ioctl (like
BLKHSSZGET) and keep the
Hi,
> Concerning fdisk, luckily you are mistaken - its source says
>
> #if defined(BLKSSZGET) && defined(HAVE_blkpg_h)
>
> so that it will not use the broken BLKSSZGET of 2.2.
??? BLKSSZGET has exactly the same ioctl number in 2.2 and 2.4, so if I
compile fdisk under 2.4 and try to use it unde
Hi,
> - BLKSSZGET added in common.h
Why don't we give BLKSSZGET a new number and make the old one obsolete? I
don't think it's used anywhere, as its result is pretty useless in
userspace (and even if it's used somewhere, they have to copy the define
anyway). This way we don't need that version c
Hi,
On Tue, 17 Oct 2000, Andries Brouwer wrote:
> But you see that one would need a new name as well,
> otherwise the value associated with BLKSSZGET would
> depend on the kernel version, and one would need
> version checks anyway.
We do rename structures too, and this would be similiar. I'm mo
Hi,
On Thu, 8 Mar 2001, God wrote:
> Look at some of the confirmation requests in windows, some ask you twice
> if you whish to perform an action. Even Red Hat (that I know of, others
> may as well), has an alias for "rm" that by
> default turns on confirmation. Why? Because not ALL users wil
Hi,
On Tue, 23 Jan 2001, Mark Mokryn wrote:
> ioremap_nocache does the following:
> return __ioremap(offset, size, _PAGE_PCD);
>
> However, in drivers/char/mem.c (2.4.0), we see the following:
>
> /* On PPro and successors, PCD alone doesn't always mean
> uncached becaus
Hi,
Timur Tabi wrote:
> I mark the page as reserved when I ioremap() it. However, if I leave it marked
> reserved, then iounmap() will not unmap it. If I mark it "unreserved" (i.e.
> reset the reserved bit), then iounmap will unmap it, but it will decrement the
> page counter to -1 and the who
Hi,
On Sun, 28 Jan 2001, Manfred Spraul wrote:
> And one more point for the Janitor's list:
> Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
> either spin_lock_irq() or spin_lock() is sufficient. That's both faster
> and better readable.
>
> spin_lock_irq(): you know that
Hi,
On Mon, 29 Jan 2001, Andi Kleen wrote:
> You can miss wakeups. The standard pattern is:
>
> get locks
>
> add_wait_queue(&waitqueue, &wait);
> for (;;) {
> if (condition you're waiting for is true)
> break;
> unlock any
Hi,
On Mon, 5 Feb 2001, Linus Torvalds wrote:
> This all proves that the lowest level of layering should be pretty much
> noting but the vectors. No callbacks, no crap like that. That's already a
> level of abstraction away, and should not get tacked on. Your lowest level
> of abstraction should
Hi,
On Mon, 5 Feb 2001, Linus Torvalds wrote:
> > Does it has to be vectors? What about lists?
>
> I'd prefer to avoid lists unless there is some overriding concern, like a
> real implementation issue. But I don't care much one way or the other -
> what I care about is that the setup and usage
Hi,
Dave Hansen wrote:
> diff -puN mm/Kconfig~A6-mm-Kconfig mm/Kconfig
> --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0
> -0700
> +++ memhotplug-dave/mm/Kconfig2005-04-04 10:15:23.0 -0700
> @@ -0,0 +1,25 @@
> +choice
> + prompt "Memory model"
> +
Hi,
On Wed, 6 Apr 2005, Dave Hansen wrote:
> On Wed, 2005-04-06 at 22:58 +0200, Roman Zippel wrote:
> > Dave Hansen wrote:
> > > --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0
> > > -0700
> > > +++ memhotplug-dave/mm/Kconfig
Hi,
On Wed, 6 Apr 2005, Dave Hansen wrote:
> > Why is this choice needed at all? Why would one choose SPARSEMEM over
> > DISCONTIGMEM?
>
> For now, it's only so people can test either one, and we don't have to
> try to toss DICONTIGMEM out of the kernel in fell swoop. When the
> memory hotplug
Hi,
On Thu, 7 Apr 2005, Linus Torvalds wrote:
> I really disliked that in BitKeeper too originally. I argued with Larry
> about it, but Larry (correctly, I believe) argued that efficient and
> reliable distribution really requires the concept of "history is
> immutable". It makes replication much
Hi,
On Fri, 8 Apr 2005, Tupshin Harper wrote:
> > A1 -> A2 -> A3 -> B1 -> B2
> >
> > This results in a simpler repository, which is more scalable and which is
> > easier for users to work with (e.g. binary bug search).
> > The disadvantage would be it will cause more minor conflicts, when ch
Hi,
On Fri, 8 Apr 2005, Linus Torvalds wrote:
> Also, I suspect that BKCVS actually bothers to get more details out of a
> BK tree than I cared about. People have pestered Larry about it, so BKCVS
> exports a lot of the nitty-gritty (per-file comments etc) that just
> doesn't actually _matter_, b
Hi,
On Fri, 8 Apr 2005, Linus Torvalds wrote:
> Yes. Per-file history is expensive in git, because if the way it is
> indexed. Things are indexed by tree and by changeset, and there are no
> per-file indexes.
>
> You could create per-file _caches_ (*) on top of git if you wanted to make
> it
Hi,
On Sat, 9 Apr 2005, Eric D. Mudama wrote:
> > For example bk does something like this:
> >
> > A1 -> A2 -> A3 -> BM
> > \-> B1 -> B2 --^
> >
> > and instead of creating the merge changeset, one could merge them like
> > this:
> >
> > A1 -> A2 -> A3 -> B1 -> B2
> >
Hi,
On Sun, 10 Apr 2005, Paul P Komkoff Jr wrote:
> (borrowed from Tommi Virtanen)
>
> Code snippet to reconstruct ancestry graph from bk repo:
> bk changes -end':I: $if(:PARENT:){:PARENT:$if(:MPARENT:){ :MPARENT:}}
> $unless(:PARENT:){-}' |tac
>
> format is:
> newrev parent1 [parent2]
Hi,
On Mon, 11 Jul 2005, Horst von Brand wrote:
> > I don't generally disagree with that, I just think that defines are not
> > part of that list.
>
> Covered in "bad coding style" and "hard to read code", at least.
Somehow I missed the last lkml debate about where simple defines where a
prob
Hi,
On Tue, 12 Jul 2005, randy_dunlap wrote:
> This appears to be a dependency bug in gconfig to me.
>
> If I enable NETCONSOLE to y, NETPOLL becomes y. (OK)
> If I then disable NETCONSOLE to n, NETPOLL remains y.
>
> If I enable NETCONSOLE to m, NETPOLL remains n. Why is that?
>
> config NE
Hi,
On Wed, 13 Jul 2005, Egry G�bor wrote:
> diff -puN scripts/kconfig/zconf.l~kconfig-i18n-18-whitespace-fix
> scripts/kconfig/zconf.l
> ---
> linux-2.6.13-rc3-i18n-kconfig/scripts/kconfig/zconf.l~kconfig-i18n-18-whitespace-fix
> 2005-07-13 18:32:20.0 +0200
> +++ linux-2.6.13-rc3
Hi,
On Wed, 13 Jul 2005, Egry G�bor wrote:
> UTF-8 support for lxdialog with wchar. The installed wide ncurses
> (ncursesw) is optional because some languages (ex. English, Italian)
> and ISO 8859-xx charsets don't require this patch.
This is ugly, this just adds lots of #ifdefs with practical
Hi,
On Wed, 13 Jul 2005, Egry G�bor wrote:
> The following patches complete the "Kconfig I18N support" patch by
> Arnaldo.
First I'd really like to see some documentation on this, which describes
the interface how tools/distributions can provide Kconfig I18N support.
> - answering (Y/M/N)
Th
Hi,
On Mon, 11 Jul 2005, Andrew Morton wrote:
> > > Hi Andrew, can you please merge relayfs? It provides a low-overhead
> > > logging and buffering capability, which does not currently exist in
> > > the kernel.
> >
> > While the code is pretty nicely in shape it seems rather pointless to
> > m
Hi,
On Thu, 14 Jul 2005, Nishanth Aravamudan wrote:
> We no longer use jiffies (the variable) as the basis for determining
> what "time" a timer should expire or when it should be added. Instead,
> we use a new function, do_monotonic_clock(), which is simply a wrapper
> for getnstimeofday().
And
Hi,
On Sun, 17 Jul 2005, Bodo Eggert wrote:
> These patches change some menus into menuconfig options.
>
> Reworked to apply to linux-2.6.13-rc3-git3
I like it, but I would prefer to give it first a bit more exposure in -mm,
as it does change the menu structure and the behaviour is little
dif
Hi,
On Thu, 14 Jul 2005, Tom Zanussi wrote:
> The netlink control channel seems to work very well, but I can
> certainly change the examples to use something different. Could you
> suggest something?
It just looks like a complicated way to do an ioctl, a control file that
you can read/write wo
Hi,
On Fri, 15 Jul 2005, john stultz wrote:
> In my attempts to rework the timeofday subsystem, it was suggested I
> try to avoid mixing cleanups with functional changes. In response to the
> suggestion I've tried to break out the majority of the NTP cleanups I've
> been working out of my l
Hi,
On Mon, 18 Jul 2005, Steven Rostedt wrote:
> I'm actually very much against this. Looking at a point of view from the
> logdev device. Having a callback to know to continue at every buffer
> switch would just be slowing down something that is expected to be very
> fast.
What exactly would be
Hi,
On Mon, 18 Jul 2005, Steven Rostedt wrote:
> > What exactly would be slowed down?
> > It would just move around some code and even avoid the overwrite mode
> > check.
>
> Yes, you're adding a jump to another function via a function pointer,
> that would kill the cache line of execution, to
Hi,
On Mon, 18 Jul 2005, Karim Yaghmour wrote:
> I guess I just don't get the point here. Why cut something away if many
> users will need it. If it's that popular that you're ready to provide a
> library function to do it, then why not just leave it to boot? One of the
> goals of relayfs is to a
Hi,
On Wed, 20 Jul 2005, john stultz wrote:
> I really don't think the NTP changes I've mailed is very complex.
> Please, be specific and point to something you think is an issue and
> I'll do my best to fix it.
Maybe I should explain, in what direction I would take it.
Let's first only take tic
Hi,
On Fri, 22 Jul 2005, Arjan van de Ven wrote:
> Also I'd rather not add the non-msec ones... either you're raw and use
> HZ, or you are "cooked" and use the msec variant.. I dont' see the point
> of adding an "in the middle" one. (Yes this means that several users
> need to be transformed to m
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> > What's wrong with using jiffies?
>
> A lot of the (driver) users want a wallclock based timeout. For that,
> miliseconds is a more obvious API with less chance to get the jiffies/HZ
> conversion wrong by the driver writer.
We have helper fun
1 - 100 of 538 matches
Mail list logo
