headers
Hubertus Franke | 1 Mar 2002 03:00
Picon
Favicon

Re: [PATCH] Lightweight userspace semaphores...

On Thu, Feb 28, 2002 at 04:24:22PM -0800, Richard Henderson wrote:
> On Wed, Feb 27, 2002 at 10:53:11AM -0500, Hubertus Franke wrote:
> > As stated above, I allocate a kernel object <kulock_t> on demand and
> > hash it. This way I don't have to pin any user address. What does everybody
> > think about the merit of this approach versus the pinning approach?
> [...]
> > In your case, can the lock be allocated at different
> > virtual addresses in the various address spaces.
> 
> I think this is a relatively important feature.  It may not be
> possible to use the same virtual address in different processes.
> 
> 
> r~

I think so too. However let me point that Linus's initial recommendation
of a handle, comprised of a kernel pointer and a signature also has
that property.
Just pointing out the merits of the various approaches.

-- Hubertus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Alan Cox | 1 Mar 2002 02:51
Picon

Re: Congrats Marcelo,

>  > sensor in the machine. Once you are using ACPI though you talk to ACPI
>  > and it talks to the smbus etc and knows whats in the box
> 
>  Given the fears of what happens when you look at i2c/smbus etc
>  the wrong way, is this something we can rely on DMI tables
>  to get right ?  When they can't get cachesize info right, I begin
>  to question their ability to describe a temperature sensor.

The ones I looked at seemed credible - but yes it is an issue 8)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Max Kamenetsky | 1 Mar 2002 03:45
Picon

Problem compiling 2.5.6-pre2 w/ OSS support

Hi!

I'm having a problem complining 2.5.6-pre2 with OSS support.  If it
matters, I'm compiling support for a Turtle Beach Fiji card as a
module.  The compilation bombs out during "make bzImage" at this point:

ld -m elf_i386 -T /usr/src/linux-2.5.6-pre2/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o
init/do_mounts.o \
        --start-group \
        arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
        /usr/src/linux-2.5.6-pre2/arch/i386/lib/lib.a /usr/src/linux-2.5.6-pre2/lib/lib.a
/usr/src/linux-2.5.6-pre2/arch/i386/lib/lib.a \
         drivers/base/base.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o
drivers/scsi/scsidrv.o drivers/cdrom/driver.o sound/sound.o drivers/pci/driver.o
drivers/pnp/pnp.o drivers/video/video.o drivers/usb/usbdrv.o drivers/input/serio/seriodrv.o \
        net/network.o \
        --end-group \
        -o vmlinux
sound/sound.o: In function `sound_alloc_dmap':
sound/sound.o(.text+0x36d9): undefined reference to `virt_to_bus_not_defined_use_pci_map'
make: *** [vmlinux] Error 1

The same problem was exhibited by 2.5.5.  I have been unable to figure
out why this is happening, so any help would be greatly appreciated.

Thanks,
    Max
-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Brown | 1 Mar 2002 02:07
X-Face
Picon
Picon
Favicon

Re: [PATCH] 2.5.5: compile error in fs/filesystems.c

On Friday March 1, olaf.dietsche--list.linux-kernel <at> exmail.de wrote:
> Hi Neil,
> 
> Neil Brown <neilb <at> cse.unsw.edu.au> writes:
> 
> > 2.5.6-pre2 already has a patch for this.
> 
> The compile error is gone, *but* ... :-)
> With 2.5.6-pre2 you get nfsd support, wether you want it or
> not. Consider this:

With 2.5.6-pre2 you will always get just enough code to be able to
load nfsd as a module later, even if you didn't compile nfsd as a
module this time.  Unless modules are disabled of course.

There have been a number of problem reports on linux-kernel over the
last year or two from people who cannot load nfsd.o as a module.
Often it is because they originally compiled without and NFSD support
at all, but subsequently decided that wanted to compile and load
nfsd.o

This works for many modules (e.g. filesystems)  It is reasonable that
it work for nfsd as well.

I thought that the cost of always including the hooks to load nfsd was
minimal, and worth the consistency/convenience.

Does that seem reasonable to you?

NeilBrown
(Continue reading)

Permalink | Reply | 1 comment |
headers
Reza Roboubi | 1 Mar 2002 01:43

Re: Async IO using threads

Btw, I mentioned that I rewrote the test to do the "useful work" using
fifos, and that gave 0.45% of the CPU back during the read() operation.

Just in case anyone wants that test, it is on the web site with the
other test:

http://www.linisoft.com/test/asyncf.c  //async using fifo
http://www.linisoft.com/test/async.c  //async using __asm__(lock)
--

-- 
Reza
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Rick Lindsley | 1 Mar 2002 01:19
Picon
Favicon

Re: ext3 and undeletion

A lot of talk about "daemons" ... seems overkill to me.  Any reason not
to let each user do this on their own?  I've got an rm/unrm program
that just stores the "rescued" files in your home directory for a
period of time based on the either the name or pathname.

It is not fully "hardened" -- it is possible to conceive of filenames
and filename/directory name pairs which will confuse it -- but it is
certainly functional for 98% of cases, which has been good enough for
my personal use.

Disadvantages:
    * the mtime is purposefully changed when the file is deleted to make
      it easy to tell when a file was "deleted", so you lose that information.
    * Directory modes and owners are not maintained.
    * File ownerships are maintained only to the extent that a hard
      link allows you to. If you couldn't do a hard link (cross file
      systems) then the "saved" file will be owned by you unless you
      are root.
    * There's no way to say "save until X amount is saved then really
      delete" (whether "X amount" is %age of file system, a fixed amount,
      or some other criteria).  The only criteria is age of deletion.
    * (true) deletions are only attempted when a subsequent file is rm'ed.
      So it's conceivable to delete 300Mb of data that is scheduled to
      disappear in 30 seconds but not have it go away for three days,
      because you left town for the weekend and neither you nor your
      cron scripts ran "rm" again until Monday.

If this sort of program is useful to folks, I'm more than happy to
provide it. No doubt it could be enhanced to address some of the
shortcomings above. I just got tired many years ago of accidentally
(Continue reading)

Permalink | Reply | 1 comment |
headers
David S. Miller | 1 Mar 2002 02:03
Picon
Favicon

Re: [Emu10k1-devel] Re: Emu10k1 SPDIF passthru doesn't work if

   From: Alan Cox <alan <at> lxorguk.ukuu.org.uk>
   Date: Fri, 1 Mar 2002 01:07:27 +0000 (GMT)

   The cast befor ethe cpu_to_ is safe if its 32bit I/O only. Maybe we should
   have cpu_to_le_dma_addr_t 8)

Actually, the cast to 32-bit is safe if you've set your DMA mask
properly :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Alan Cox | 1 Mar 2002 01:22
Picon

Re: Kernel module ethics.

> Anyway, you're not distributing your kernel with your module linked in,
> so you're not distributing a derivative of a GPLed program, so by my
> understanding section 2b doesn't apply.  Comments?

Look up "derivative work". Its nothing to do with programmer think
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |
headers
Rik van Riel | 1 Mar 2002 03:17
Picon
Favicon

[PATCH] cleanups struct page shrinkage

Hi Linus,

during the merge of the struct page shrinkage patch with 2.4
two issues came up:

- janitor: clean up i810_dma.c and agpgart_be.c to use the macros
  from mm.h instead of set_bit/clear_bit
- access page->count only through the atomic macros, remove the
  broken init_page_count thing  (DaveM)

I've ported these things to 2.5 now, diffstat and unidiff below
my .sig, you can pull the changeset from:

   bk://linuxvm.bkbits.net/linux-2.5-vmtidbits

please consider for a next 2.5 kernel.

thank you,

Rik
--

-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

 drivers/char/agp/agpgart_be.c |   40 +++++++++++++++++-----------------------
 drivers/char/drm/i810_dma.c   |    9 ++++-----
 include/linux/mm.h            |    5 -----
 mm/page_alloc.c               |    2 +-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Cox | 1 Mar 2002 02:04
Picon

Re: 2.4.19-preX: What we really need: -AA patches finally in the

> or (c) have proponents of the inclusion of the O(1) scheduler
> fix all drivers before having the O(1) scheduler considered
> for inclusion.

According to find and grep the patch in general use does precisely that
except for Andrea's yield loops on init kill funnies that still lurk in
the non x86 parts of rmap. If rmap doesnt need them I guess they should go ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Permalink | Reply | 0 comments |

Gmane