[Stgt-devel] [PATCH] add stgt_device_template example

[FUJITA Tomonori]

From: Mike Christie <michaelc at cs.wisc.edu>
Subject: Re: [Stgt-devel] [PATCH] add stgt_device_template example
Date: Thu, 25 Aug 2005 10:23:43 -0500

> > Do you mean using netlink by adding STGT_UEVENT_TARGET_CREATE, etc?
> 
> I am not sure about STGT_UEVENT_TARGET_CREATE, becuase of HW target 
> drivers though. Will they need it or use it? I thought we were going to 
> end up in a similar situation as we have for software iscsi vs HW cards. 
> It is probably best to do what we can with what we have and if HW 
> targets do not need it then that is fine. What do you think?

Agree. Probabaly, some HW target drivers need to directly access
stgt_target_create/destroy in kernel space.

Some HW target drivers can use netlink about target configuration, I
guess. Chelsio cards seem to use the following scheme to configure
targets.

1. The user-space configuration tool reads the configuration file.
2. It tells the kernel modules by using ioctl.

So if stgt provides some callback mechanisms (that you mentioned
below), Chelsio driver may work well with the netlink scheme.


> I think there should be a STGT_UEVENT_DEVICE_CREATE though. The target 
> drivers do not seem to have to hanlde that part.

Yep. Now stgt_device_create/destroy can be accessed only though
netlink.


> > If you have not started to work on this and I understand correctly,
> > I'll do it if you want.
> 
> ok go ahead.

UEVENT_DEVICE stuff is done (though IET cannot still shut down
cleanly), however, the interface need to be improved later.

How should stgt handle a very log param like 'path'? I put it in
netlink's payload, however, should I put it in struct stgt_event?

I'll clean up the user-space stgt code because it is really messy.


> > Does stgt enable target drivers to call their own functions when
> > user-space requires such operations?
> 
> I think we will need to move the stgt_target_template registration to 
> the target driver's module_init function. We can add some callbacks onto 
> it so stgt can call into the target driver. Maybe a create_target(), 
> set_param(), get_param(), destroy_target(), etc is needed. I think this 
> is what you are suggesting right?

I think so. I simply thought about mechanisms like
stgt_device_template, however, I didn't have a clear idea. I'll
implement that after the cleanup.