From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267143AbTAFVQp>; Mon, 6 Jan 2003 16:16:45 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267145AbTAFVQp>; Mon, 6 Jan 2003 16:16:45 -0500
Received: from mail110.mail.bellsouth.net ([205.152.58.50]:4318 "EHLO
	imf10bis.bellsouth.net") by vger.kernel.org with ESMTP
	id <S267143AbTAFVQo>; Mon, 6 Jan 2003 16:16:44 -0500
Subject: status on the new driver model?
From: Louis Garcia <louisg00@bellsouth.net>
To: linux-kernel@vger.kernel.org
Content-Type: text/plain
Organization: 
Message-Id: <1041888351.12319.15.camel@tiger>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 (1.2.1-2) 
Date: 06 Jan 2003 16:25:51 -0500
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

What is the status of the new driver model? Are the driver being ported
over in a timely fashion? Is this process going to be complete before the
code freeze/2.6? I've heard the PCI bus and drivers are not yet converted
to strut devices? Oh, is the old LDM or what ever is was being riped out
or left for compatibility?

Thanks, --Lou


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267204AbTAFVdr>; Mon, 6 Jan 2003 16:33:47 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267208AbTAFVdr>; Mon, 6 Jan 2003 16:33:47 -0500
Received: from 12-231-249-244.client.attbi.com ([12.231.249.244]:62981 "HELO
	kroah.com") by vger.kernel.org with SMTP id <S267204AbTAFVdq>;
	Mon, 6 Jan 2003 16:33:46 -0500
Date: Mon, 6 Jan 2003 13:42:20 -0800
From: Greg KH <greg@kroah.com>
To: Louis Garcia <louisg00@bellsouth.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: status on the new driver model?
Message-ID: <20030106214220.GA22207@kroah.com>
References: <1041888351.12319.15.camel@tiger>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1041888351.12319.15.camel@tiger>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Jan 06, 2003 at 04:25:51PM -0500, Louis Garcia wrote:
> What is the status of the new driver model?

It's currently working, mount sysfs and take a look.

> Are the driver being ported over in a timely fashion?

Yes.

> Is this process going to be complete before the code freeze/2.6?

Depends, are you willing to help out?  :)

> I've heard the PCI bus and drivers are not yet converted to strut
> devices?

Not true at all, have you even looked at the current 2.5 code?

> Oh, is the old LDM or what ever is was being riped out or left for
> compatibility?

What "old LDM"?

Again, you can find all the answers to your questions by actually
looking at the code.

thanks,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267188AbTAFW0B>; Mon, 6 Jan 2003 17:26:01 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267187AbTAFWZN>; Mon, 6 Jan 2003 17:25:13 -0500
Received: from 12-231-249-244.client.attbi.com ([12.231.249.244]:15878 "HELO
	kroah.com") by vger.kernel.org with SMTP id <S267184AbTAFWZL>;
	Mon, 6 Jan 2003 17:25:11 -0500
Date: Mon, 6 Jan 2003 14:33:46 -0800
From: Greg KH <greg@kroah.com>
To: Emiliano Gabrielli <emiliano.gabrielli@roma2.infn.it>
Cc: linux-kernel@vger.kernel.org
Subject: Re: status on the new driver model?
Message-ID: <20030106223346.GA22844@kroah.com>
References: <1041888351.12319.15.camel@tiger> <20030106214220.GA22207@kroah.com> <32886.62.98.199.114.1041890715.squirrel@webmail.roma2.infn.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <32886.62.98.199.114.1041890715.squirrel@webmail.roma2.infn.it>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Jan 06, 2003 at 11:05:15PM +0100, Emiliano Gabrielli wrote:
> 
> Where can I find Docs about the new device drivers model ??
> Anybody cat gimme some links where I cat get docs ?!?

Look in the Documentation/driver-model directory in the kernel.

thanks,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267187AbTAFXBY>; Mon, 6 Jan 2003 18:01:24 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267190AbTAFXBY>; Mon, 6 Jan 2003 18:01:24 -0500
Received: from cpe.atm2-0-1071115.0x50c4d862.boanxx10.customer.tele.dk ([80.196.216.98]:23181
	"EHLO fugmann.dhs.org") by vger.kernel.org with ESMTP
	id <S267187AbTAFXBX>; Mon, 6 Jan 2003 18:01:23 -0500
Message-ID: <3E1A0CC8.6000802@fugmann.dhs.org>
Date: Tue, 07 Jan 2003 00:10:00 +0100
From: Anders Fugmann <afu@fugmann.dhs.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9
MIME-Version: 1.0
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: status on the new driver model?
References: <1041888351.12319.15.camel@tiger> <20030106214220.GA22207@kroah.com>
In-Reply-To: <20030106214220.GA22207@kroah.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Greg KH wrote:
> On Mon, Jan 06, 2003 at 04:25:51PM -0500, Louis Garcia wrote:
>>Is this process going to be complete before the code freeze/2.6?
> 
> Depends, are you willing to help out?  :)
I'm voluntering to try and make some porting/cleanup. Are there some 
good small modules that needs porting (Lets start easy)?

Regards
Anders Fugmann




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267582AbTAGU57>; Tue, 7 Jan 2003 15:57:59 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267591AbTAGU57>; Tue, 7 Jan 2003 15:57:59 -0500
Received: from air-2.osdl.org ([65.172.181.6]:20115 "EHLO mail.osdl.org")
	by vger.kernel.org with ESMTP id <S267582AbTAGU5k>;
	Tue, 7 Jan 2003 15:57:40 -0500
Date: Tue, 7 Jan 2003 14:20:25 -0600 (CST)
From: Patrick Mochel <mochel@osdl.org>
X-X-Sender: <mochel@localhost.localdomain>
To: Anders Fugmann <afu@fugmann.dhs.org>
cc: Greg KH <greg@kroah.com>, <linux-kernel@vger.kernel.org>
Subject: Re: status on the new driver model?
In-Reply-To: <3E1A0CC8.6000802@fugmann.dhs.org>
Message-ID: <Pine.LNX.4.33.0301071408360.1020-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


On Tue, 7 Jan 2003, Anders Fugmann wrote:

> Greg KH wrote:
> > On Mon, Jan 06, 2003 at 04:25:51PM -0500, Louis Garcia wrote:
> >>Is this process going to be complete before the code freeze/2.6?
> > 
> > Depends, are you willing to help out?  :)
> I'm voluntering to try and make some porting/cleanup. Are there some 
> good small modules that needs porting (Lets start easy)?

Great, glad to hear it.

I would suggest at least browsing Documentation/driver-model/*.txt and
reading the appended document. (I've responded to several similar emails
in the past, and realized there was no master document for describing
this, so I decided to write one.)

Hopefully, this is useful to you and others. I'll be adding this to
Documentation/driver-model/.

In general, the driver model infrastructure (and kobject infrastructure)  
are all about using generically defined objects and routines, rather than
duplicating them again and again. Because of that, most of the changes
happen at a high level (i.e. in the bus driver) rather than at the
low-level (i.e. in the driver modules).

The appended document describes how to convert a bus driver to the new
model, which covers the representation of devices and device drivers. It
is a gradual process that can be done in several steps.

If you don't feel up to taking on an entirely unconverted driver, please
feel free to help out with ones that are already underway, including:

- PCI 
- USB
- SCSI
- IDE
- MCA
- ISA 

Alternatively, if someone doesn't feel up to converting the drivers,
something that would be really handy would be a list of all bus types and
device classes that the kernel supports, and the drivers that belong to
each. It's not necessarily an easy list to compile, but again something
that can happen gradually. ;)

	-pat



Porting Drivers to the New Driver Model


Overview

Please refer to Documentation/driver-model/*.txt for definitions of
various driver types and concepts. 

Most of the work of porting devices drivers to the new model happens
at the bus driver layer. This was intentional, to minimize the
negative effect on kernel drivers, and to allow a gradual transition
of bus drivers.

In a nutshell, the driver model consists of a set of objects that can
be embedded in larger, bus-specific objects. Fields in these generic
objects can replace fields in the bus-specific objects. 

The generic objects must be registered with the driver model core. By
doing so, they will exported via the sysfs filesystem. sysfs can be
mounted by doing 

	# mount -t sysfs sysfs /sys



The Process

Step 0: Read include/linux/device.h for object and function definitions. 

Step 1: Registering the bus driver. 


- Define a struct bus_type for the bus driver.

struct bus_type pci_bus_type = {
        .name           = "pci",
};


- Register the bus type.
  This should be done in the initialization function for the bus type,
  which is usually the module_init(), or equivalent, function. 

static int __init pci_driver_init(void)
{
        return bus_register(&pci_bus_type);
}

subsys_initcall(pci_driver_init);


  The bus type may be unregistered (if the bus driver may be compiled
  as a module) by doing:

     bus_unregister(&pci_bus_type);


- Export the bus type for others to use. 

  Other code may wish to reference the bus type, so declare it in a 
  shared header file and export the symbol.

>>From include/linux/pci.h:

extern struct bus_type pci_bus_type;


>>From file the above code appears in:

EXPORT_SYMBOL(pci_bus_type);



- This will cause the bus to show up in /sys/bus/pci/ with two
  subdirectories: 'devices' and 'drivers'.

# tree -d /sys/bus/pci/
/sys/bus/pci/
|-- devices
`-- drivers



Step 2: Registering Devices. 

struct device represents a single device. It mainly contains metadata
describing the relationship the device has to other entities. 


- Embedd a struct device in the bus-specific device type. 


struct pci_dev {
       ...
       struct  device  dev;            /* Generic device interface */
       ...
};

  It is recommended that the generic device not be the first item in 
  the struct to discourage programmers from doing mindless casts
  between the object types. Instead macros, or inline functions,
  should be created to convert from the generic object type.


#define to_pci_dev(n) container_of(n, struct pci_dev, dev)

or 

static inline struct pci_dev * to_pci_dev(struct kobject * kobj)
{
	return container_of(n, struct pci_dev, dev);
}

  This allows the compiler to verify type-safety of the operations 
  that are performed (which is Good).


- Initialize the device on registration.

  When devices are discovered or registered with the bus type, the 
  bus driver should initialize the generic device. The most important
  things to initialize are the bus_id, parent, and bus fields.

  The bus_id is an ASCII string that contains the device's address on
  the bus. The format of this string is bus-specific. This is
  necessary for representing device in sysfs. 

  parent is the physical parent of the device. It is important that
  the bus driver sets this field correctly. 

  The driver model maintains an ordered list of devices that it uses
  for power management. This list must be in order to guarantee that
  devices are shutdown before their physical parents, and vice versa.
  The order of this list is determined by the parent of registered
  devices.

  Also, the location of the device's sysfs directory depends on a
  device's parent. sysfs exports a directory structure that mirrors 
  the device hierarchy. Accurately setting the parent guarantees that
  sysfs will accurately represent the hierarchy.

  The device's bus field is a pointer to the bus type the device
  belongs to. This should be set to the bus_type that was declared
  and initialized before. 

  Optionally, the bus driver may set the device's name and release
  fields.

  The name field is an ASCII string describing the device, like

     "ATI Technologies Inc Radeon QD"

  The release field is a callback that the driver model core calls 
  when the device has been removed, and all references to it have 
  been released. More on this in a moment.


- Register the device. 

  Once the generic device has been initialized, it can be registered
  with the driver model core by doing:

       device_register(&dev->dev);

  It can later be unregistered by doing: 

       device_unregister(&dev->dev);

  This should happen on buses that support hotpluggable devices. 
  If a bus driver unregisters a device, it should not immediately free
  it. It should instead wait for the driver model core to call the 
  device's release method, then free the bus-specific object. 
  (There may be other code that is currently referencing the device
  structure, and it would be rude to free the device while that is 
  happening).


  When the device is registered, a directory in sysfs is created. 
  The PCI tree in sysfs looks like: 

/sys/devices/pci0/
|-- 00:00.0
|-- 00:01.0
|   `-- 01:00.0
|-- 00:02.0
|   `-- 02:1f.0
|       `-- 03:00.0
|-- 00:1e.0
|   `-- 04:04.0
|-- 00:1f.0
|-- 00:1f.1
|   |-- ide0
|   |   |-- 0.0
|   |   `-- 0.1
|   `-- ide1
|       `-- 1.0
|-- 00:1f.2
|-- 00:1f.3
`-- 00:1f.5

  Also, symlinks are created in the bus's 'devices' directory
  that point to the device's directory in the physical hierarchy. 

/sys/bus/pci/devices/
|-- 00:00.0 -> ../../../devices/pci0/00:00.0
|-- 00:01.0 -> ../../../devices/pci0/00:01.0
|-- 00:02.0 -> ../../../devices/pci0/00:02.0
|-- 00:1e.0 -> ../../../devices/pci0/00:1e.0
|-- 00:1f.0 -> ../../../devices/pci0/00:1f.0
|-- 00:1f.1 -> ../../../devices/pci0/00:1f.1
|-- 00:1f.2 -> ../../../devices/pci0/00:1f.2
|-- 00:1f.3 -> ../../../devices/pci0/00:1f.3
|-- 00:1f.5 -> ../../../devices/pci0/00:1f.5
|-- 01:00.0 -> ../../../devices/pci0/00:01.0/01:00.0
|-- 02:1f.0 -> ../../../devices/pci0/00:02.0/02:1f.0
|-- 03:00.0 -> ../../../devices/pci0/00:02.0/02:1f.0/03:00.0
`-- 04:04.0 -> ../../../devices/pci0/00:1e.0/04:04.0



Step 3: Registering Drivers.

struct device_driver is a simple driver structure that contains a set
of operations that the driver model core may call. 


- Embed a struct device_driver in the bus-specific driver. 

  Just like with devices, do something like:

struct pci_driver {
       ...
       struct device_driver    driver;
};


- Initialize the generic driver structure. 

  When the driver registers with the bus (e.g. doing pci_register_driver()),
  initialize the necessary fields of the driver: the name and bus
  fields. 


- Register the driver.

  After the generic driver has been initialized, call

	driver_register(&drv->driver);

  to register the driver with the core.

  When the driver is unregistered from the bus, unregister it from the
  core by doing:

        driver_unregister(&drv->driver);

  Note that this will block until all references to the driver have
  gone away. Normally, there will not be any.


- Sysfs representation.

  Drivers are exported via sysfs in their bus's 'driver's directory. 
  For example:

/sys/bus/pci/drivers/
|-- 3c59x
|-- Ensoniq AudioPCI
|-- agpgart-amdk7
|-- e100
`-- serial


Step 4: Define Generic Methods for Drivers.

struct device_driver defines a set of operations that the driver model
core calls. Most of these operations are probably similar to
operations the bus already defines for drivers, but taking different
parameters. 

It would be difficult and tedious to force every driver on a bus to
simultaneously convert their drivers to generic format. Instead, the
bus driver should define single instances of the generic methods that
forward calls to the bus-specific drivers. For instance: 


static int pci_device_remove(struct device * dev)
{
        struct pci_dev * pci_dev = to_pci_dev(dev);
        struct pci_driver * drv = pci_dev->driver;

        if (drv) {
                if (drv->remove)
                        drv->remove(pci_dev);
                pci_dev->driver = NULL;
        }
        return 0;
}


The generic driver should be initialized with these methods before it
is registered. 

        /* initialize common driver fields */
        drv->driver.name = drv->name;
        drv->driver.bus = &pci_bus_type;
        drv->driver.probe = pci_device_probe;
        drv->driver.resume = pci_device_resume;
        drv->driver.suspend = pci_device_suspend;
        drv->driver.remove = pci_device_remove;

        /* register with core */
        driver_register(&drv->driver);


Ideally, the bus should only initialize the fields if they are not
already set. This allows the drivers to implement their own generic
methods. 


Step 5: Support generic driver binding. 

The model assumes that a device or driver can be dynamically
registered with the bus at any time. When registration happens,
devices must be bound to a driver, or drivers must be bound to all
devices that it supports. 

Drivers typically contain a list of device IDs that it supports. The
bus driver compares this ID to the ID of devices registered with it. 
The format of the device IDs, and the semantics for comparing them are
bus-specific, so the generic model does attempt to generalize them. 

Instead, a bus may supply a method in struct bus_type that does the
comparison: 

  int (*match)(struct device * dev, struct device_driver * drv);

match should return '1' if the driver supports the device, and '0'
otherwise. 

When a device is registered, the bus's list of drivers is iterated
over. bus->match() is called for each one until a match is found. 

When a driver is registered, the bus's list of devices is iterated
over. bus->match() is called for each device that is not already
claimed by a driver. 

When a device is successfully bound to a device, device->driver is
set, the device is added to a per-driver list of devices, and a
symlink is created in the driver's sysfs directory that points to the
device's physical directory:

/sys/bus/pci/drivers/
|-- 3c59x
|   `-- 00:0b.0 -> ../../../../devices/pci0/00:0b.0
|-- Ensoniq AudioPCI
|-- agpgart-amdk7
|   `-- 00:00.0 -> ../../../../devices/pci0/00:00.0
|-- e100
|   `-- 00:0c.0 -> ../../../../devices/pci0/00:0c.0
`-- serial


This driver binding should replace the existing driver binding
mechanism the bus currently uses. 


Step 6: Supply a hotplug callback.

Whenever a device is registered with the driver model core, the
userspace program /sbin/hotplug is called to notify userspace. 
Users can define actions to perform when a device is inserted or
removed. 

The driver model core passes several arguments to userspace via
environment variables, including

- ACTION: set to 'add' or 'remove'
- DEVPATH: set to the device's physical path in sysfs. 

A bus driver may also supply additional parameters for userspace to
consume. To do this, a bus must implement the 'hotplug' method in
struct bus_type:

     int (*hotplug) (struct device *dev, char **envp, 
                     int num_envp, char *buffer, int buffer_size);

This is called immediately before /sbin/hotplug is executed. 


Step 7: Cleaning up the bus driver.

The generic bus, device, and driver structures provide several fields
that can replace those define privately to the bus driver. 

- Device list.

struct bus_type contains a list of all devices registered with the bus
type. This includes all devices on all instances of that bus type.
An internal list that the bus uses may be removed, in favor of using
this one.

The core provides an iterator to access these devices. 

int bus_for_each_dev(struct bus_type * bus, struct device * start, 
                     void * data, int (*fn)(struct device *, void *));


- Driver list.

struct bus_type also contains a list of all drivers registered with
it. An internal list of drivers that the bus driver maintains may 
be removed in favor of using the generic one. 

The drivers may be iterated over, like devices: 

int bus_for_each_drv(struct bus_type * bus, struct device_driver * start,
                     void * data, int (*fn)(struct device_driver *, void *));


Please see drivers/base/bus.c for more information.


- rwsem 

struct bus_type contains an rwsem that protects all core accesses to
the device and driver lists. This can be used by the bus driver
internally, and should be used when accessing the device or driver
lists the bus maintains. 


- Device and driver fields. 

Some of the fields in struct device and struct device_driver duplicate
fields in the bus-specific representations of these objects. Feel free
to remove the bus-specific ones and favor the generic ones. Note
though, that this will likely mean fixing up all the drivers that
reference the bus-specific fields (though those should all be 1-line
changes).



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267982AbTAHXql>; Wed, 8 Jan 2003 18:46:41 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267983AbTAHXqh>; Wed, 8 Jan 2003 18:46:37 -0500
Received: from intra.cyclades.com ([64.186.161.6]:2830 "EHLO
	intra.cyclades.com") by vger.kernel.org with ESMTP
	id <S267982AbTAHXqg>; Wed, 8 Jan 2003 18:46:36 -0500
Message-ID: <3E1C4927.4020101@cyclades.com>
Date: Wed, 08 Jan 2003 15:52:07 +0000
From: Henrique Gobbi <henrique2.gobbi@cyclades.com>
Reply-To: henrique.gobbi@cyclades.com
Organization: Cyclades Corporation
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
Subject: modutils x 2.5.54
References: <Pine.LNX.4.33.0301071408360.1020-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi all !!!

Which version of modutils am I suppose to use with the kernel 2.5.54 ???
Where can I find it ???

thanks in advance
Henrique


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267987AbTAHXwM>; Wed, 8 Jan 2003 18:52:12 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267988AbTAHXwM>; Wed, 8 Jan 2003 18:52:12 -0500
Received: from air-2.osdl.org ([65.172.181.6]:60590 "EHLO mail.osdl.org")
	by vger.kernel.org with ESMTP id <S267987AbTAHXwA>;
	Wed, 8 Jan 2003 18:52:00 -0500
Date: Wed, 8 Jan 2003 15:57:09 -0800 (PST)
From: "Randy.Dunlap" <rddunlap@osdl.org>
X-X-Sender: <rddunlap@dragon.pdx.osdl.net>
To: <henrique.gobbi@cyclades.com>
cc: <linux-kernel@vger.kernel.org>
Subject: Re: modutils x 2.5.54
In-Reply-To: <3E1C4927.4020101@cyclades.com>
Message-ID: <Pine.LNX.4.33L2.0301081556320.6873-100000@dragon.pdx.osdl.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 8 Jan 2003, Henrique Gobbi wrote:

| Hi all !!!
|
| Which version of modutils am I suppose to use with the kernel 2.5.54 ???
| Where can I find it ???

Latest.

It's here: (from Documentation/Change file):
o  <ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/modules/>

-- 
~Randy


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267721AbTAIAm3>; Wed, 8 Jan 2003 19:42:29 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267725AbTAIAm3>; Wed, 8 Jan 2003 19:42:29 -0500
Received: from mta8.algx.net ([67.92.168.237]:14136 "EHLO chimta03.algx.net")
	by vger.kernel.org with ESMTP id <S267721AbTAIAm3>;
	Wed, 8 Jan 2003 19:42:29 -0500
Date: Wed, 08 Jan 2003 16:50:47 -0800
From: "studio3arc.com Admin" <admin@studio3arc.com>
Subject: RE: modutils x 2.5.54
In-reply-to: <Pine.LNX.4.33L2.0301081556320.6873-100000@dragon.pdx.osdl.net>
To: "'Randy.Dunlap'" <rddunlap@osdl.org>, henrique.gobbi@cyclades.com
Cc: linux-kernel@vger.kernel.org
Message-id: <001601c2b779$2748bf40$6601a8c0@s3ac>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook, Build 10.0.2616
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

ect: Re: modutils x 2.5.54
> 
> 
> On Wed, 8 Jan 2003, Henrique Gobbi wrote:
> 
> | Hi all !!!
> |
> | Which version of modutils am I suppose to use with the 
> kernel 2.5.54 
> | ??? Where can I find it ???

Is there a way to tell if your compile was successful like a ****
--version command ?


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267729AbTAIAtN>; Wed, 8 Jan 2003 19:49:13 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267731AbTAIAtN>; Wed, 8 Jan 2003 19:49:13 -0500
Received: from mta6.algx.net ([67.92.168.235]:12336 "EHLO chimta05.algx.net")
	by vger.kernel.org with ESMTP id <S267729AbTAIAtM>;
	Wed, 8 Jan 2003 19:49:12 -0500
Date: Wed, 08 Jan 2003 16:57:33 -0800
From: "studio3arc.com Admin" <admin@studio3arc.com>
Subject: RE: modutils x 2.5.54
In-reply-to: <Pine.LNX.4.33L2.0301081649500.6873-100000@dragon.pdx.osdl.net>
To: "'Randy.Dunlap'" <rddunlap@osdl.org>
Cc: henrique.gobbi@cyclades.com, linux-kernel@vger.kernel.org
Message-id: <001701c2b77a$18336630$6601a8c0@s3ac>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook, Build 10.0.2616
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


> modprobe --version
> gives me 0.9.5.
> 
> lsmod and insmod don't support --version.
> 

I get the following 2.4.12 !?!? Now I'm very confused


s3a-www:/usr/src/linux-2.4.18.SuSE # modprobe --version
modprobe version 2.4.12
modprobe: Nothing to load ???
Specify at least a module or a wildcard like \*
s3a-www:/usr/src/linux-2.4.18.SuSE #


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267727AbTAIApP>; Wed, 8 Jan 2003 19:45:15 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267728AbTAIApO>; Wed, 8 Jan 2003 19:45:14 -0500
Received: from air-2.osdl.org ([65.172.181.6]:12740 "EHLO mail.osdl.org")
	by vger.kernel.org with ESMTP id <S267727AbTAIApO>;
	Wed, 8 Jan 2003 19:45:14 -0500
Date: Wed, 8 Jan 2003 16:50:20 -0800 (PST)
From: "Randy.Dunlap" <rddunlap@osdl.org>
X-X-Sender: <rddunlap@dragon.pdx.osdl.net>
To: "studio3arc.com Admin" <admin@studio3arc.com>
cc: <henrique.gobbi@cyclades.com>, <linux-kernel@vger.kernel.org>
Subject: RE: modutils x 2.5.54
In-Reply-To: <001601c2b779$2748bf40$6601a8c0@s3ac>
Message-ID: <Pine.LNX.4.33L2.0301081649500.6873-100000@dragon.pdx.osdl.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 8 Jan 2003, studio3arc.com Admin wrote:

| ect: Re: modutils x 2.5.54
| >
| >
| > On Wed, 8 Jan 2003, Henrique Gobbi wrote:
| >
| > | Hi all !!!
| > |
| > | Which version of modutils am I suppose to use with the
| > kernel 2.5.54
| > | ??? Where can I find it ???
|
| Is there a way to tell if your compile was successful like a ****
| --version command ?

modprobe --version
gives me 0.9.5.

lsmod and insmod don't support --version.

-- 
~Randy


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S267726AbTAIAzz>; Wed, 8 Jan 2003 19:55:55 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S267730AbTAIAzz>; Wed, 8 Jan 2003 19:55:55 -0500
Received: from air-2.osdl.org ([65.172.181.6]:37576 "EHLO mail.osdl.org")
	by vger.kernel.org with ESMTP id <S267726AbTAIAzy>;
	Wed, 8 Jan 2003 19:55:54 -0500
Date: Wed, 8 Jan 2003 17:01:00 -0800 (PST)
From: "Randy.Dunlap" <rddunlap@osdl.org>
X-X-Sender: <rddunlap@dragon.pdx.osdl.net>
To: "studio3arc.com Admin" <admin@studio3arc.com>
cc: <henrique.gobbi@cyclades.com>, <linux-kernel@vger.kernel.org>
Subject: RE: modutils x 2.5.54
In-Reply-To: <001701c2b77a$18336630$6601a8c0@s3ac>
Message-ID: <Pine.LNX.4.33L2.0301081659230.6873-100000@dragon.pdx.osdl.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 8 Jan 2003, studio3arc.com Admin wrote:

|
| > modprobe --version
| > gives me 0.9.5.
| >
| > lsmod and insmod don't support --version.
| >
|
| I get the following 2.4.12 !?!? Now I'm very confused
|
|
| s3a-www:/usr/src/linux-2.4.18.SuSE # modprobe --version
| modprobe version 2.4.12
| modprobe: Nothing to load ???
| Specify at least a module or a wildcard like \*
| s3a-www:/usr/src/linux-2.4.18.SuSE #

Did you install the new mod-utils?  ('make install' as root)
and how did you tell the new mod-utils that you want to use them?
Sounds like you need to read the README and INSTALL files...

-- 
~Randy


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261205AbTAIBCl>; Wed, 8 Jan 2003 20:02:41 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261286AbTAIBCl>; Wed, 8 Jan 2003 20:02:41 -0500
Received: from [213.228.128.91] ([213.228.128.91]:11659 "HELO
	front3.netvisao.pt") by vger.kernel.org with SMTP
	id <S261205AbTAIBCk>; Wed, 8 Jan 2003 20:02:40 -0500
Subject: RE: modutils x 2.5.54
From: "Paulo Andre'" <fscked@netvisao.pt>
To: linux-kernel@vger.kernel.org
In-Reply-To: <001701c2b77a$18336630$6601a8c0@s3ac>
References: <001701c2b77a$18336630$6601a8c0@s3ac>
Content-Type: text/plain
Organization: Corleone Hacking Corp.
Message-Id: <1042074675.28495.4.camel@nostromo.orion.int>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 09 Jan 2003 01:11:15 +0000
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 2003-01-09 at 00:57, studio3arc.com Admin wrote:
> > modprobe --version
> > gives me 0.9.5.
> > 
> > lsmod and insmod don't support --version.
> > 
> 
> I get the following 2.4.12 !?!? Now I'm very confused
> 
> 
> s3a-www:/usr/src/linux-2.4.18.SuSE # modprobe --version
> modprobe version 2.4.12
> modprobe: Nothing to load ???
> Specify at least a module or a wildcard like \*
> s3a-www:/usr/src/linux-2.4.18.SuSE #

If you are running a 2.5 kernel then it seems you didn't install the
module-init-tools correctly. It's supposed to install the newer utils as
modutils, lsmod, insmod etc.. and backups the old modutils as
modprobe.old, lsmod.old, insmod.old and so on. 

Either that or you are running a 2.4 kernel, in which case the output is
correct (or so it seems).

	Paulo


