(no subject)

[redzic fadil]

hello


I hope I don't disturb,


I have tried to compile the hello.c module under kernel 2.6.3.
And I'd like to insert the hello.o module in the kernel.
But this doesn't work with kernel 2.6.3 .

I have compiled this module with kernel 2.4.* and it is well.

Also I cannot include the header file module.h, because I get error 
messages.

my module:
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>


int initial_module (void)
{
	printk("\ninitial module\n");
	return (0);
}

void delete_module (void)
{
	printk("\ndelete module\n");
}

module_init(initial_module);
module_exit(delete_module);


my Makefile:
CC=gcc
CFLAGS=-isystem /lib/modules/`uname -r`/build/include -O2 -D__KERNEL__ 
-DMODULE
all: hello.o

If you have any idea please send an E-Mail:  redzic_fadil@hotmail.com

thanks

_________________________________________________________________
Die ultimative Fan-Seite für den MSN Messenger http://www.ilovemessenger.de 
Emoticons und Hintergründe kostenlos downloaden!

Re:

[Larry Reaves]

I suggest that you read
http://linuxdevices.com/articles/AT4389927951.html it is an article
about the differences between modules for 2.4 and 2.6.  Basically all
you need to do to get it to work is delete your Makefile and create a
new one with only this line:
obj-m := hello.o
and then issue the following command:
make -C /usr/src/linux-2.6.3 SUBDIRS=$PWD modules
your module compiles fine on my box using this method

On Sun, 2004-02-22 at 12:51, redzic fadil wrote:
> hello
> 
> 
> I hope I don't disturb,
> 
> 
> I have tried to compile the hello.c module under kernel 2.6.3.
> And I'd like to insert the hello.o module in the kernel.
> But this doesn't work with kernel 2.6.3 .
> 
> I have compiled this module with kernel 2.4.* and it is well.
> 
> Also I cannot include the header file module.h, because I get error 
> messages.
> 
> my module:
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
> 
> 
> int initial_module (void)
> {
> 	printk("\ninitial module\n");
> 	return (0);
> }
> 
> void delete_module (void)
> {
> 	printk("\ndelete module\n");
> }
> 
> module_init(initial_module);
> module_exit(delete_module);
> 
> 
> my Makefile:
> CC=gcc
> CFLAGS=-isystem /lib/modules/`uname -r`/build/include -O2 -D__KERNEL__ 
> -DMODULE
> all: hello.o
> 
> If you have any idea please send an E-Mail:  redzic_fadil@hotmail.com
> 
> thanks
> 
> _________________________________________________________________
> Die ultimative Fan-Seite für den MSN Messenger http://www.ilovemessenger.de
> Emoticons und Hintergründe kostenlos downloaden!
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Larry Reaves <larry@moonshinecomputers.com>

Re: No Subject

[Ludootje]

On Sun, 2004-02-22 at 17:51, redzic fadil wrote:
> hello
> 
> 
> I hope I don't disturb,
> 
> 
> I have tried to compile the hello.c module under kernel 2.6.3.
> And I'd like to insert the hello.o module in the kernel.
> But this doesn't work with kernel 2.6.3 .
> 
> I have compiled this module with kernel 2.4.* and it is well.


See http://lwn.net/Articles/21817 for porting hello world.
(or http://lwn.net/Articles/driver-porting for the entire article)

Ludootje

No subject

[auto595907]

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16423
Subject		: netfilter/iptables stopped logging 2.6.35-rc
Submitter	: auto401300@hushmail.com
Date		: 2010-07-17 10:20 (44 days old)
Message-ID	: <20100717072036.1BBE52804B@smtp.hushmail.com>
References	: 
http://lkml.indiana.edu/hypermail/linux/kernel/1007.2/00440.html


this patch fixes the bug above:
(http://marc.info/?l=netfilter-devel&m=128116762801769&w=2)

fixed in 2.6.36-rc3


thanks

No subject

[auto595907]

>I created a Bugzilla entry at 
>https://bugzilla.kernel.org/show_bug.cgi?id=16423
>for your bug report, please add your address to the CC list in 
>there, thanks!
>
>-- 
>Maciej Rutecki
>http://www.maciek.unixy.pl


this patch fixes the bug above
(http://marc.info/?l=netfilter-devel&m=128116762801769&w=2)


thanks.

Re: No Subject

[Alan Cox]

The Xen interface seems to me better described that most of the kernel
interfaces and has more papers written on it. I would rather see
arch/xen and public exposure and use of the platform before considering
major redesigns. The s390 people have proved we can remove/fold arch
directories effectively and after original implementation without
problems.

I'm not convinced by your arguments about arch/xen although I am long
term in favour because I'd like see it easy to build a kernel which can
be used without Xen and can switch into Xen guest mode on Xen loading.

Alan

Re: No Subject

[Jesse Stockall]

On Fri, 2004-07-16 at 12:54, Hermann Gottschalk wrote:
> unsubscribe

Please follow the instructions at the bottom of every message.

Jesse

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

Re: No Subject

[Alan Cox]

On Fri, 2003-02-21 at 13:43, News Admin wrote:
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.3/specs
> Configured with: ../src/configure -v
> --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared
> --with-system-zlib --enable-nls --without-included-gettext
> --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm
> --enable-objc-gc i386-linux
> Thread model: posix
> gcc version 3.2.3 20030210 (Debian prerelease)

How about using a released gcc compiler not a snapshot. gcc 3.2.1
and 3.2.2 appear to work fine. According to the FSF there is no
gcc 3.2.3 yet, so it isn't suprising a snapshot would have bugs

Re: No Subject

[Alan Cox]

Red Hat put out an errata for the 2.4.7-10 kernel a long time ago. It
fixes numerous problems and indirect bugs as a result. Can you try that
first of all

Re: No Subject

[Daniela Engert]

On Sun, 4 Aug 2002 13:28:46 +0000 (UTC), Henning P. Schmiedehausen
wrote:

>Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> writes:
>>On 4 Aug 2002, Alan Cox wrote:
>>> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:

>>> > Just rethough it. What if chipset is in compatibility mode?
>>> > Like VIA with base addresses set to 0?
>>>
>>> If we found a register that was marked as unassigned with a size then we
>>> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
>>> device attached to the south bridge.
>
>>In compatibility mode IDE chipsets have IO at legacy ISA ports and
>>PCI_BASE_ADDRESS0-3 are set to them or to zero (at least on VIA).
>>And they can't be programmed to any other ports (unless native mode).

>this sounds like a problem that I have with the ServerWorks OSB5
>chipset. I actually have PCI_BASE_ADDRESS0-3 at 0 and
>PCI_BASE_ADDRESS4 = 0x3a0.
>
>Does this hold true here, too? Or is this VIA specific?

PCI IDE controller chips in compatibility mode may exhibit the
following BAR0-3 values (sorted by likelihood of occurance):

most likely:  BAR0-3 are all zero
rare       :  BAR0-3 show the legacy IDE port values
very rare  :  BAR0-3 contain garbage

In fact, the best strategy is to *ignore* BAR0-3 in compatibility mode
because they have no meaning then!

Ciao,
  Dani

Re: No Subject

[Henning P. Schmiedehausen]

Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> writes:

>On 4 Aug 2002, Alan Cox wrote:

>> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
>> > Just rethough it. What if chipset is in compatibility mode?
>> > Like VIA with base addresses set to 0?
>>
>> If we found a register that was marked as unassigned with a size then we
>> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
>> device attached to the south bridge.
>>
>> What problems does that cause for the VIA stuff ?

>In compatibility mode IDE chipsets have IO at legacy ISA ports and
>PCI_BASE_ADDRESS0-3 are set to them or to zero (at least on VIA).
>And they can't be programmed to any other ports (unless native mode).

Hi,

this sounds like a problem that I have with the ServerWorks OSB5
chipset. I actually have PCI_BASE_ADDRESS0-3 at 0 and
PCI_BASE_ADDRESS4 = 0x3a0.

Does this hold true here, too? Or is this VIA specific?

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: No Subject

[Alan Cox]

On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
> Just rethough it. What if chipset is in compatibility mode?
> Like VIA with base addresses set to 0?

If we found a register that was marked as unassigned with a size then we
would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
device attached to the south bridge.

What problems does that cause for the VIA stuff ?

Re: No Subject

[Petr Vandrovec]

On Sun, Aug 04, 2002 at 12:38:00AM +0100, Alan Cox wrote:
> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
> > Just rethough it. What if chipset is in compatibility mode?
> > Like VIA with base addresses set to 0?
> 
> If we found a register that was marked as unassigned with a size then we
> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
> device attached to the south bridge.
> 
> What problems does that cause for the VIA stuff ?

We must read PCI config register 9 (programming interface), and check its value.

If r9 & 0x05 == 0x05, we can program BARs. 

Otherwise if r9 & 0x0A != 0x0A, we must not touch hardware: it supports 
only legacy 0x1F0/0x170 assignment (PCI-IDE spec says that BAR0-BAR3
can be either hardwired to zero, or it can be writeable, but written
value must be ignored).

If r9 & 0x0A == 0x0A, we must write r9 | 0x05 to PCI config register 9,
and then (after verifying that write suceeded... it does not suceed
in VMware, for example...) we must (re)program BARs.

Worst problem is that (some) VIA chips have BAR0-BAR3 writeable,
but are programmed to ignore them by BIOS (as IRQ14/IRQ15 routing is
not available when in native mode). Current kernel code will believe
that device was relocated, but reality will be different, because of device
ignores BAR0-BAR3 value until programming interface is modified.
					Best regards,
						Petr Vandrovec
						vandrove@vc.cvut.cz

Re: No Subject

[Bartlomiej Zolnierkiewicz]

On 4 Aug 2002, Alan Cox wrote:

> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
> > Just rethough it. What if chipset is in compatibility mode?
> > Like VIA with base addresses set to 0?
>
> If we found a register that was marked as unassigned with a size then we
> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
> device attached to the south bridge.
>
> What problems does that cause for the VIA stuff ?

In compatibility mode IDE chipsets have IO at legacy ISA ports and
PCI_BASE_ADDRESS0-3 are set to them or to zero (at least on VIA).
And they can't be programmed to any other ports (unless native mode).

I am just asking if it can cause some problems.

--
Bartlomiej

Re: No Subject

[Bartlomiej Zolnierkiewicz]

On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:

>
> On 3 Aug 2002, Alan Cox wrote:
>
> > On Sat, 2002-08-03 at 20:26, Pawel Kot wrote:
> > > What helped me was using fixup_device_piix() from -ac in
> > > ide_scan_pcidev(). My controler's ID is DEVID_ICH3M.
> > > It is used in a different, more generic way in -ac, so I don't post the
> > > patch.
> > >
> > > Alan, Marcelo: is there any chance that this change will be ported from
> > > -ac in 2.4.20?
> >
> > I plan to send Marcelo all the IDE updates. Note btw the checking of the
> > return value on pci_enable_device is critical - some old kernels hang on
> > boot with crappy bioses through not checking.
>
> Of course it is critical :-).
>
> > What I begin to the think the right answer is, is to relax the IDE fixup
> > block in the i386 kernel boot up. Right now we avoid assigning
> > unassigned resources for IDE controllers. Clearly we should be doing so.
>
> I think so.
> Andre what do you think?

Just rethough it. What if chipset is in compatibility mode?
Like VIA with base addresses set to 0?

(please note I am not a PCI resource menagament expert ;-)

> And one more thing in ide-pci.c:ide_setup_pci_device() after explicitly
> enabling device's IOs we may need to update dev->resource and we don't
> do this (we place chipset in native mode so i.e. on VIA base addresses
> are just showing up). How to update them?
>
> Regards
> --
> Bartlomiej

Re: No Subject

[Bartlomiej Zolnierkiewicz]

On 3 Aug 2002, Alan Cox wrote:

> On Sat, 2002-08-03 at 20:26, Pawel Kot wrote:
> > What helped me was using fixup_device_piix() from -ac in
> > ide_scan_pcidev(). My controler's ID is DEVID_ICH3M.
> > It is used in a different, more generic way in -ac, so I don't post the
> > patch.
> >
> > Alan, Marcelo: is there any chance that this change will be ported from
> > -ac in 2.4.20?
>
> I plan to send Marcelo all the IDE updates. Note btw the checking of the
> return value on pci_enable_device is critical - some old kernels hang on
> boot with crappy bioses through not checking.

Of course it is critical :-).

> What I begin to the think the right answer is, is to relax the IDE fixup
> block in the i386 kernel boot up. Right now we avoid assigning
> unassigned resources for IDE controllers. Clearly we should be doing so.

I think so.
Andre what do you think?

And one more thing in ide-pci.c:ide_setup_pci_device() after explicitly
enabling device's IOs we may need to update dev->resource and we don't
do this (we place chipset in native mode so i.e. on VIA base addresses
are just showing up). How to update them?

Regards
--
Bartlomiej

Re: No Subject

[Alan Cox]

On Sat, 2002-08-03 at 20:26, Pawel Kot wrote:
> What helped me was using fixup_device_piix() from -ac in
> ide_scan_pcidev(). My controler's ID is DEVID_ICH3M.
> It is used in a different, more generic way in -ac, so I don't post the
> patch.
> 
> Alan, Marcelo: is there any chance that this change will be ported from
> -ac in 2.4.20?

I plan to send Marcelo all the IDE updates. Note btw the checking of the
return value on pci_enable_device is critical - some old kernels hang on
boot with crappy bioses through not checking.

What I begin to the think the right answer is, is to relax the IDE fixup
block in the i386 kernel boot up. Right now we avoid assigning
unassigned resources for IDE controllers. Clearly we should be doing so.

No Subject

[abraxas2]

hi everybody,

i have implemented an improved linux ntfs driver.

the following changes have been done :

- full deletion support
- full hardlink support
- support for multiple mft records
- support for chmod, rename, truncate, df, du, ...
- implemented new tools ntchmod, ntlink, ntrm, ntundel (undeletion)
  there is a NT port of the tools, too
- fixed a bunch of FIXME's and another bunch of bugs

the kernel part of the sources increased almost to the double.

one of the performed tests was a complete linux kernel build on a
ntfs volume. without any complaints by chkdsk.


this is currently for kernel 2.2.x.

work is in progress for the following items :
- support for kernel 2.4.x
- support for symlinks, device files and chown/chgrp
- full support for compressed files

if you are interested, please send me an email. please indicate if you
want only the kernel part or the complete sources.

Abraxas

<abraxas2@findhere.com>