login
Search
Please consider for inclusion, an in-kernel OSD initiator library. Its main users are planned to be various OSD based file systems and the pNFS-Objects Layout Driver. (To be submitted soon) To try out and run the library please visit http://open-osd.org and follow the instructions there. The submitted patchset is also available via git at: git://git.open-osd.org/linux-open-osd.git osd http://git.open-osd.org/gitweb.cgi?p=linux-open-osd.git;a=shortlog;h=osd Or a compact out-of-tree repository that includes sources and some extras: git://git.open-osd.org/open-osd.git master http://git.open-osd.org/gitweb.cgi?p=open-osd.git;a=summary The submitted patches add public header files to include/scsi/ for use by other subsystems. The source files and private headers are put at a new drivers/scsi/osd/ directory, with the privilege of a separate Makefile and Kconfig. here is the list of patches: [PATCH 01/18] major.h: char-major number for OSD device driver A request for a new char-device major number [PATCH 02/18] scsi: OSD_TYPE The OSD scsi type constant definition. [PATCH 03/18] libosd: OSDv1 Headers [PATCH 04/18] libosd: OSDv1 preliminary implementation Most basic, but usable library module (libosd.ko) including Kbuild/Makefile. [PATCH 05/18] osd_uld: OSD scsi ULD [PATCH 06/18] osd_uld: API for retrieving osd devices from Kernel [PATCH 07/18] osd_test: User-mode application to run the OSD tests [PATCH 08/18] osd_ktests: Add basic OSD tests These patches add a scsi ULD for OSD type devices. Please see commit logs for details. [PATCH 09/18] libosd: attributes Support [PATCH 10/18] osd_ktests: Test Attribute lists [PATCH 11/18] libosd: OSD Security processing stubs [PATCH 12/18] libosd: Add Flush and List-objects support [PATCH 13/18] libosd: Not implemented commands [PATCH 14/18] libosd: OSD version 2 Support [PATCH 15/18] libosd: OSDv2 auto detection Up to here this is a fairly complete body of work, to support both OSD1 and ...
- Define the OSD_TYPE scsi device and let it show up in scans Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> --- drivers/scsi/scsi_scan.c | 1 + include/scsi/scsi.h | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index b14dc02..633cb87 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -783,6 +783,7 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result, case TYPE_ENCLOSURE: case TYPE_COMM: case TYPE_RAID: + case TYPE_OSD: sdev->writeable = 1; break; case TYPE_ROM: diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h index a109165..de1cef2 100644 --- a/include/scsi/scsi.h +++ b/include/scsi/scsi.h @@ -263,6 +263,7 @@ static inline int scsi_status_is_good(int status) #define TYPE_RAID 0x0c #define TYPE_ENCLOSURE 0x0d /* Enclosure Services Device */ #define TYPE_RBC 0x0e +#define TYPE_OSD 0x11 #define TYPE_NO_LUN 0x7f /* SCSI protocols; these are taken from SPC-3 section 7.5 */ -- 1.6.0.1 --
Headers only patch.
osd_protocol.h
Contains a C-fied definition of the T10 OSD standard
osd_types.h
Contains CPU order common used types
osd_initiator.h
API definition of the osd_initiator library
osd_sec.h
Contains High level API for the security manager.
[Note that checkpatch spews errors on things that are valid in this context
and will not be fixed]
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
include/scsi/osd_initiator.h | 332 ++++++++++++++++++++++++++++
include/scsi/osd_protocol.h | 497 ++++++++++++++++++++++++++++++++++++++++++
include/scsi/osd_sec.h | 45 ++++
include/scsi/osd_types.h | 40 ++++
4 files changed, 914 insertions(+), 0 deletions(-)
create mode 100644 include/scsi/osd_initiator.h
create mode 100644 include/scsi/osd_protocol.h
create mode 100644 include/scsi/osd_sec.h
create mode 100644 include/scsi/osd_types.h
diff --git a/include/scsi/osd_initiator.h b/include/scsi/osd_initiator.h
new file mode 100644
index 0000000..24a70b7
--- /dev/null
+++ b/include/scsi/osd_initiator.h
@@ -0,0 +1,332 @@
+/*
+ * osd_initiator.h - OSD initiator API definition
+ *
+ * Copyright (C) 2008 Panasas Inc. All rights reserved.
+ *
+ * Authors:
+ * Boaz Harrosh <bharrosh@panasas.com>
+ * Benny Halevy <bhalevy@panasas.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ *
+ */
+#ifndef __OSD_INITIATOR_H__
+#define __OSD_INITIATOR_H__
+
+#include <linux/blkdev.h>
+
+#include "osd_protocol.h"
+#include "osd_types.h"
+
+/* Note: "NI" in comments below means "Not Implemented yet" */
+
+/*
+ * Object-based Storage Device.
+ * This object represents an OSD device.
+ * It is not a full linux device in any way. It is only
+ * a place to hang resources associated with a Linux
+ * request Q and some default properties.
+ */
+struct osd_dev {
+ struct scsi_device ...On Tue, 4 Nov 2008 18:44:06 +0200 This header uses quite a few things without including the header files which define them. That's a bit risky - it causes compile breakage hm. It appears that someone made the decision to omit the name from the `struct osd_request *' parameter in the prototypes and to include the argument names for all other arguments. Not a bad idea, really. --
One easy way to review 98% is to include the header in an otherwise empty foo.c and compile that. The remaining 2% are hidden behind different config options and architectures. Although your header may be fine on that front. Jörn -- He who knows others is wise. He who knows himself is enlightened. -- Lao Tsu --
Btw, running such a script on include/linux detects a lot of trouble even with i386 allnoconfig. Most of which looks it could be 'fixed' by a drunken monkey inserting #includes. But some of those #includes may be fs.h and pull the kitchensink, adding tons of dependencies and some compile time. Unsure. Jörn -- Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson --
I have done just that. It's an old habit of mine. The very first #include in osd_initiator.c is osd_initiator.h precisely for that. So it's not just a one time test it's always tested. Thanks Boaz --
It's OK. I'm very pedantic about these things.
The first header included at osd_initiator.c is this header precisely
for the check Jörn has suggested. What happens is that all the types
in osd_initiator.h are actually derived from osd_protocol.h below.
osd_protocol.h does include exactly what it needs. (Also checked)
The only new definitions used by this header are from linux/blkdev.h
hence included here.
Do you mean that I need to use __u64? or what do you mean?
I will change it. but just for curiosity, I have seen this mentioned
once before, but never understood. What's wrong with the uXX types?
I include linux/types.h and I get them as well as the __uXX set.
Why are we not suppose to use them? And if we are not, then why do
they exist? And also why the u8 is used everywhere but the u{16-64}
are not?
(Please for give me for attacking so strongly I just personally like
I prefer my name. I've seen the gfp_t use in Kernel, but I needed
It's a programing style thing. The "this" parameter name is dropped
for been obvious and redundant. I like to keep the Header files
most readable and self-documenting. I know that in C, the style is
to look at .c files for answers, but I borrowed the C++ way of
making it as easy as possible on the user and summarizing all exported
types and services at the header file. Not just for the sake of the compiler
but also for the reader.
Note that I put the kernel-doc comments in the header and not in the
source file.
Thank you for your comments
Boaz
--
He means you've used u64 in a header without actually including any file that defines the typedef. Linux header files aren't supposed to depend on include order. They're supposed to stand alone. The point is that if I include just #include osd_initiator.h into an empty kernel file it's not supposed to spit undefined errors. Right at the moment the u64 probably works because blkdev.h #includes the file which defines it, but you're not supposed to rely on that. James --
I have addressed that issue. The osd_initiator.h includes the osd_protocol.h file. osd_protocol.h does include all the types needed. All of the osd_initiator.h types are derived from osd_protocol.h, the only added definitions are from blkdev.h. The very first #include in osd_initiator.c is osd_initiator.h which preforms exactly the check you suggest. Boaz --
Headers only patch.
osd_protocol.h
Contains a C-fied definition of the T10 OSD standard
osd_types.h
Contains CPU order common used types
osd_initiator.h
API definition of the osd_initiator library
osd_sec.h
Contains High level API for the security manager.
[Note that checkpatch spews errors on things that are valid in this context
and will not be fixed]
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
include/scsi/osd_initiator.h | 332 ++++++++++++++++++++++++++++
include/scsi/osd_protocol.h | 497 ++++++++++++++++++++++++++++++++++++++++++
include/scsi/osd_sec.h | 45 ++++
include/scsi/osd_types.h | 40 ++++
4 files changed, 914 insertions(+), 0 deletions(-)
create mode 100644 include/scsi/osd_initiator.h
create mode 100644 include/scsi/osd_protocol.h
create mode 100644 include/scsi/osd_sec.h
create mode 100644 include/scsi/osd_types.h
diff --git a/include/scsi/osd_initiator.h b/include/scsi/osd_initiator.h
new file mode 100644
index 0000000..9bab95d
--- /dev/null
+++ b/include/scsi/osd_initiator.h
@@ -0,0 +1,332 @@
+/*
+ * osd_initiator.h - OSD initiator API definition
+ *
+ * Copyright (C) 2008 Panasas Inc. All rights reserved.
+ *
+ * Authors:
+ * Boaz Harrosh <bharrosh@panasas.com>
+ * Benny Halevy <bhalevy@panasas.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ *
+ */
+#ifndef __OSD_INITIATOR_H__
+#define __OSD_INITIATOR_H__
+
+#include "osd_protocol.h"
+#include "osd_types.h"
+
+#include <linux/blkdev.h>
+
+/* Note: "NI" in comments below means "Not Implemented yet" */
+
+/*
+ * Object-based Storage Device.
+ * This object represents an OSD device.
+ * It is not a full linux device in any way. It is only
+ * a place to hang resources associated with a Linux
+ * request Q and some default properties.
+ */
+struct osd_dev {
+ struct scsi_device ...__packed can result in slow code being generated. But removing the
attribute can lead to bugs on other architectures. F.e. the size of
the structure below is different for i386 and x86_64.
struct foo {
u64 bar;
u32 baz;
};
My personal solution is to use this little macro and then just follow
every structure defition with a size check.
#define SIZE_CHECK(type, size) \
static inline void check_##type(void) \
{ \
BUILD_BUG_ON(sizeof(struct type) != (size)); \
}
...
struct foo {
u64 bar;
u32 baz;
};
SIZE_CHECK(foo, 12);
The above would not compile on x86_64 and clearly indicate a missing
__packed. In other cases the attribute can be removed.
Jörn
--
Invincibility is in oneself, vulnerability is in the opponent.
-- Sun Tzu
--
Hi Jörn Thank you for your comments I do have a size check that governs the complete structure it is the first code in osd_initiator.c at build_test(). It will catch any discrepancies from the protocol. I have done some experimentation with __packed both on 32 and 64 bit x86. When it does nothing like the above foo in 32bit, then there is no code difference with it or with out it, but on 64bit I must have it otherwise the structure grows. These are all, on-the-wire structures. I must have __packed, otherwise I'm at the compiler mercy and that's bad. If the assembly - size and offsets - of foo is exactly the same with or without the __packed, but the generated code is different then clearly this is a compiler bug. I've herd of this myth before, and at least with my gcc 4.1.2 there is no such bug. Either the structure gets packed, or there is no difference. All the places I have __packed in the code are absolutely must be so, stated by the protocol. Boaz --
Ok, if current compilers are fine, I won't complain. Jörn -- There's nothing better for promoting creativity in a medium than making an audience feel "Hmm I could do better than that!" -- Douglas Adams in a slashdot interview --
Don't mix having parameter names and not having them.
Don't start comment blocks with /** when they are not kernel-doc,
and don't start each line with a Capital letter since they are not the
beginning of sentences. What's with that period ('.') before "or->async_error"
---
~Randy
--
Thank you Randy for your review, I will post a fixed patch shortly. I have changed according to your comments I don't know what got into me. I thought it would be more readable this I've changed the comment as it was not clear it is now: OK, I must confess my kernel-doc total ignorance. I was imagining that each source file's kernel-doc comments are collected into an html file. I thought that this comment will be like an introduction to the following OK I re-worded so it will fit in one line. What happens if it does not fit, both name and description, in 80 characters? is there a continuation I would, please, like to keep them. For the user it does not matter. Because he is not suppose to care if he is doing: - memset(och->permissions_bit_mask, 0, 5); // BAD + memset(och->permissions_bit_mask, 0, sizeof(och->permissions_bit_mask)); // GOOD But for the protocol reader / debuggerer this is much easier since this is the way he will see them on the wire and the way it is laid out in the standard text. It was much easier to read the standard text and develop the header this way, complicated by the fact that OSD v2 was a moving target and the changes from OSD v1. And it helped in finding bugs. Now to go over all of them and calculate the difference and remove it. I'm loosing information, and I feel sad to loose it. Thanks Boaz --
You can choose to have comments included in the kernel-doc's collected output. You do this by using this notation: /** DOC <topic_name>: * <these lines are added to kernel-doc output when you use: !P<filename> <topic_name> * a Documentation/DocBook/*.tmpl file. */ See Documentation/DocBook/mac80211.tmpl for examples. Johannes, I thought that you had some usage documentation for DOC:. Did you not or did it not get merged?? Nope. It can (a) be longer than 80 characters (an exception is made here) or (b) split up like this: /** * func_name - some short description here * @prm1: prm1 description * @prmn: prmn description * * <longer function description here> I've debugged plenty of code so I'll respectfully disagree with you. It's confusing and ugly. But I don't control whether it is merged upstream -- ~Randy --
OK Thanks I'll give it a shot OK So I guess I took (b). Thanks. If it's "confusing and ugly" then that's bad. I guess I'm so much into the standard-text, that I like it this way, but not so for an onlooker. I'll change it. Last thing I want is ugly confusing code. Thanks again Boaz --
I honestly don't remember! Grepping through all my old patches didn't find anything though, so I suspect I didn't have anything. johannes
Headers only patch.
osd_protocol.h
Contains a C-fied definition of the T10 OSD standard
osd_types.h
Contains CPU order common used types
osd_initiator.h
API definition of the osd_initiator library
osd_sec.h
Contains High level API for the security manager.
[Note that checkpatch spews errors on things that are valid in this context
and will not be fixed]
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
include/scsi/osd_initiator.h | 332 ++++++++++++++++++++++++++++
include/scsi/osd_protocol.h | 497 ++++++++++++++++++++++++++++++++++++++++++
include/scsi/osd_sec.h | 45 ++++
include/scsi/osd_types.h | 40 ++++
4 files changed, 914 insertions(+), 0 deletions(-)
create mode 100644 include/scsi/osd_initiator.h
create mode 100644 include/scsi/osd_protocol.h
create mode 100644 include/scsi/osd_sec.h
create mode 100644 include/scsi/osd_types.h
diff --git a/include/scsi/osd_initiator.h b/include/scsi/osd_initiator.h
new file mode 100644
index 0000000..1d92247
--- /dev/null
+++ b/include/scsi/osd_initiator.h
@@ -0,0 +1,332 @@
+/*
+ * osd_initiator.h - OSD initiator API definition
+ *
+ * Copyright (C) 2008 Panasas Inc. All rights reserved.
+ *
+ * Authors:
+ * Boaz Harrosh <bharrosh@panasas.com>
+ * Benny Halevy <bhalevy@panasas.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ *
+ */
+#ifndef __OSD_INITIATOR_H__
+#define __OSD_INITIATOR_H__
+
+#include "osd_protocol.h"
+#include "osd_types.h"
+
+#include <linux/blkdev.h>
+
+/* Note: "NI" in comments below means "Not Implemented yet" */
+
+/*
+ * Object-based Storage Device.
+ * This object represents an OSD device.
+ * It is not a full linux device in any way. It is only
+ * a place to hang resources associated with a Linux
+ * request Q and some default properties.
+ */
+struct osd_dev {
+ struct scsi_device ...Thanks for the fixes. --- ~Randy --
Yes Yes that was version 3 where I was asking if I might convince you for its merits. As I said in that reply I will change it. Just did not have the chance to send out version 4 out yet. Thanks Boaz --
Headers only patch.
osd_protocol.h
Contains a C-fied definition of the T10 OSD standard
osd_types.h
Contains CPU order common used types
osd_initiator.h
API definition of the osd_initiator library
osd_sec.h
Contains High level API for the security manager.
[Note that checkpatch spews errors on things that are valid in this context
and will not be fixed]
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
include/scsi/osd_initiator.h | 332 ++++++++++++++++++++++++++++
include/scsi/osd_protocol.h | 497 ++++++++++++++++++++++++++++++++++++++++++
include/scsi/osd_sec.h | 45 ++++
include/scsi/osd_types.h | 40 ++++
4 files changed, 914 insertions(+), 0 deletions(-)
create mode 100644 include/scsi/osd_initiator.h
create mode 100644 include/scsi/osd_protocol.h
create mode 100644 include/scsi/osd_sec.h
create mode 100644 include/scsi/osd_types.h
diff --git a/include/scsi/osd_initiator.h b/include/scsi/osd_initiator.h
new file mode 100644
index 0000000..1d92247
--- /dev/null
+++ b/include/scsi/osd_initiator.h
@@ -0,0 +1,332 @@
+/*
+ * osd_initiator.h - OSD initiator API definition
+ *
+ * Copyright (C) 2008 Panasas Inc. All rights reserved.
+ *
+ * Authors:
+ * Boaz Harrosh <bharrosh@panasas.com>
+ * Benny Halevy <bhalevy@panasas.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ *
+ */
+#ifndef __OSD_INITIATOR_H__
+#define __OSD_INITIATOR_H__
+
+#include "osd_protocol.h"
+#include "osd_types.h"
+
+#include <linux/blkdev.h>
+
+/* Note: "NI" in comments below means "Not Implemented yet" */
+
+/*
+ * Object-based Storage Device.
+ * This object represents an OSD device.
+ * It is not a full linux device in any way. It is only
+ * a place to hang resources associated with a Linux
+ * request Q and some default properties.
+ */
+struct osd_dev {
+ struct scsi_device ...Acked-and-liked-by me too :-) Benny --
Implementation of the most basic OSD functionality and infrastructure. Mainly Format, Create/Remove Partition, Create/Remove Object, and read/write. - Add Makefile and Kbuild to compile libosd.ko - osd_initiator.c Implementation file for osd_initiator.h and osd_sec.h APIs - osd_debug.h - Some kprintf macro definitions Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Reviewed-by: Benny Halevy <bhalevy@panasas.com> --- drivers/scsi/osd/Kbuild | 26 +++ drivers/scsi/osd/Makefile | 37 +++ drivers/scsi/osd/osd_debug.h | 27 +++ drivers/scsi/osd/osd_initiator.c | 450 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 540 insertions(+), 0 deletions(-) create mode 100644 drivers/scsi/osd/Kbuild create mode 100755 drivers/scsi/osd/Makefile create mode 100644 drivers/scsi/osd/osd_debug.h create mode 100644 drivers/scsi/osd/osd_initiator.c diff --git a/drivers/scsi/osd/Kbuild b/drivers/scsi/osd/Kbuild new file mode 100644 index 0000000..b4678e0 --- /dev/null +++ b/drivers/scsi/osd/Kbuild @@ -0,0 +1,26 @@ +# +# Kbuild for the OSD modules +# +# Copyright (C) 2008 Panasas Inc. All rights reserved. +# +# Authors: +# Boaz Harrosh <bharrosh@panasas.com> +# Benny Halevy <bhalevy@panasas.com> +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License version 2 +# + +ifneq ($(OSD_INC),) +# we are built out-of-tree Kconfigure everything as on + +CONFIG_SCSI_OSD_INITIATOR=m +EXTRA_CFLAGS += -DCONFIG_SCSI_OSD_INITIATOR -DCONFIG_SCSI_OSD_INITIATOR_MODULE + +EXTRA_CFLAGS += -I$(OSD_INC) +# EXTRA_CFLAGS += -DCONFIG_SCSI_OSD_DEBUG + +endif + +libosd-objs := osd_initiator.o +obj-$(CONFIG_SCSI_OSD_INITIATOR) += libosd.o diff --git a/drivers/scsi/osd/Makefile b/drivers/scsi/osd/Makefile new file mode 100755 index 0000000..d905344 --- /dev/null +++ b/drivers/scsi/osd/Makefile @@ -0,0 +1,37 @@ +# +# Makefile for the OSD modules (out of tree) +# +# Copyright ...
A few comments below. When you submit for inclusion please clean this up. 1) use ccflags-y as replacement for EXTRA_CFLAGS kernel-doc comments for all exported funtions / variables. --
This is a most valuable information thanks. I have copy pasted these stuff, while learning. I guess from the wrong I have some kernel-doc comments of exported functions in the Header file. I have not yet finished all of them. (Laziness on my part). Are kernel-doc comments in headers a big NO-NO. I like it this way, so when I have to learn a new Library all the information I need to know is in the header. Also the header is a much better place when you do programing by shopping, that is you don't know what you need and you look for what's available. Thanks Boaz --
Sam please comment if kernel-doc comments are OK in headers Thanks Boaz --
Hi, The de facto standard for kernel-doc comments is at the implementation site, which means normally in .c files, except for macros or inline functions. Sure you can find some exceptions to that. And there is no hard requirement in Documentation/kernel-doc-nano-HOWTO.txt. IMO the biggest concern is making sure that the (kernel-doc) comments are updated when the function implementation changes (if updates are needed). Where would be the best place for this to be more likely to happen? Usually at the function implementation, I would say. ~Randy -- ~Randy --
Thanks Randy I would like to keep them in the Headers then. This is because I make sure that the implementation includes the declaring header, so any miss-matches are caught by the compiler. And because these are all library routines exported to other modules. The important thing is the API you linked with. If the API/parametrization change it must first change in the header. The internal implementation is not documented only the external black-box functionality is documented in these places. I will think about it some more, but for now, if it's OK I would like to keep them like submitted. In this particular library they make more sense to me in the header. Boaz --
Hardly any file in the kernel can be compiled without including
<linux/types.h>, directly or indirectly. And I'd wager a beer that
noone can find a non-trivial example. I couldn't.
So instead of sprinkling even more #include <linux/types.h> everywhere -
140 headers in include/linux/ would need that to compile standalone -
let us just pass it automatically.
The existing 4000 odd includes for types.h, plus some 300 each for
compiler.h and stddef.h, which get pulled through types.h, can get
removed at leasure.
diff --git a/Makefile b/Makefile
index 6192922..8a3fb66 100644
--- a/Makefile
+++ b/Makefile
@@ -326,7 +326,8 @@ AFLAGS_KERNEL =
# Needed to be compatible with the O= option
LINUXINCLUDE := -Iinclude \
$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
- -include include/linux/autoconf.h
+ -include include/linux/autoconf.h \
+ -include include/linux/types.h
KBUILD_CPPFLAGS := -D__KERNEL__ $(LINUXINCLUDE)
--
This is only going to slow down compilation and types.h is not causing much compilation problems, in fact, I can't recall a compilation problem due to types.h. Contary to config.h situation which was a pain. --
[ Threading should have been broken. Doh! ] My hope was actually to speed up compilation. If the average c file includes 10 headers, on types.h will get included by most of them, possibly multiple times. Each run after the first still has to parse the whole file, just to drop everything between #ifndef _LINUX_TYPES_H and #endif. By passing types.h on the command line we can drop it from all headers and only have to parse it once. Just the intermediate step of parsing types.h 11 times instead of 10 will slow things down. By about .4% on my not very beefy notebook. Before: real 4m33.241s user 3m58.524s sys 0m18.539s After: real 4m29.707s user 3m59.674s sys 0m18.182s And while testing this I noticed that a_flags shouldn't include the file. Updated patch below. Jörn -- to show off how geeky they were. -- Rob Enderle diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index ea48b82..328f345 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -121,7 +121,8 @@ endif c_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(KBUILD_CPPFLAGS) \ $(__c_flags) $(modkern_cflags) \ - -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags) + -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags) \ + -include include/linux/types.h a_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(KBUILD_CPPFLAGS) \ $(__a_flags) $(modkern_aflags) --
Actually GCC is smart enought to note the bracketing and avoid even looking at it a second time. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." --
And after removing all explicit #include <linux/types.h> from headers: real 4m31.946s user 3m59.521s sys 0m18.752s All this may be lost in the noise. The build machine wasn't completely idle and the variation in system time is rather random. So it neither helps nor hurts much. Nor does it solve any real problem. We might just as well drop it, I guess. Jörn -- The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- Douglas Adams --
If you are working on improving compile times, it's better concentrate on removing unneeded includes. If just removing "extern"s from prototypes can reliably save several seconds, reducing headers can do wonders. --
My goal was more to assume we want all headers to compile standalone and see where that would lead. Result for include/linux/ was some 500 added lines, 170 of which were to add types.h or compiler.h. Another 50-100 further includes were fairly well-spread across the spectrum. The remainder was declarations like struct super_block; Overall we have three evils to choose from. Headers with unresolved dependencies lead to random compile breakage after removing a header from some .c file. Even if the change was tested, it can still break for some config/architecture combination month down the line. Sprinkling more includes throughout the headers increase compile time. And the common practice of declaring a structure instead of including the header is a pita when working with ctags. The last problem is particularly annoying since I have no idea what problem this warning is supposed to solve: In file included from include/linux/coda_cache.c:1: include/linux/coda_cache.h:18: warning: ‘struct super_block’ declared inside parameter list include/linux/coda_cache.h:18: warning: its scope is only this definition or declaration, which is probably not what you want Should we just teach gcc to shut up about that one? Jörn -- Anything that can go wrong, will. -- Finagle's Law --
I think that if: [A] <header1.h> /* no includes pure level A header */ </header1.h> [B] <header2.h> #include "header1.h" /* Level B header depends on level A */ </header2.h> [C] <header3.h> #include "header2.h" use some types of header1.h /* Level C header depends on level B */ </header3.h> [D] <source.c> #include "header3.h" use types from A, B, C </source.c> Then that's fine any other file that includes any one of A, B, or C will have no problem compiling and headers include order does not matter. Actually it is nice, since the reader of header3.h knows that it is derived/dependent work of header2.h. Now what happens in the future when at B #include "header1.h" is removed. At C header3.h stops compiling. So here I think it is the programmer's decision. If he thinks that usage of A types used at C are do to B and if B's implementation changes to use another set of types, then also C should change with it. Then leave it as above. If the programmer decides that there is independent use of A types in C unrelated to B, then he should also include A directly. If in doubt just don't include it. In any case I'm still not breaking the self-contained / order-independent headers rule. So please don't do that, Most of these places you found are the A-B-C case Just my $0.017 Boaz --
On Tue, 4 Nov 2008 18:44:29 +0200 These two functions can/should be made static. Please generally check for this. Also it'd probably make sense to declare both these inline. The Boy, that's a scary function. bye-bye data. --
Thanks, I usually do, but these are from the last iteration and were I do not inline them, because one - I will use mem_pools very soon they are just place holders for now. two - I let the compiler do that, I made sure the only user is below the definition and I let the compiler decide. I like to leave these things controlled from outside, so when I compile a UML kernel and finally need to fire up a debugger, I can un-inline them very easily. (This is why I hate forward declarations. If they are not used Thank's for mentioning that. I use it at the very end just before the de-allocation of the block request. What happens today is: that if for some reason the driver failed to call blk_end_request, or in this case the driver was never called, the last blk_put_request() will leak BIOs. There are currently corner cases and bugs in the Kernel that cause exactly that. That loop above should be moved from here to inside blk_put_request(). if some one needs to hold the BIOs longer then the life span of the request they should simply inc-ref them. Note that here it is totally safe since It's only called just before blk_put_request(). This code is actually a bug fix, for the error cases when a request is allocated but is never executed do to other error returns. Thanks Boaz --
Implementation of the most basic OSD functionality and infrastructure. Mainly Format, Create/Remove Partition, Create/Remove Object, and read/write. - Add Makefile and Kbuild to compile libosd.ko - osd_initiator.c Implementation file for osd_initiator.h and osd_sec.h APIs - osd_debug.h - Some kprintf macro definitions Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Reviewed-by: Benny Halevy <bhalevy@panasas.com> --- drivers/scsi/osd/Kbuild | 26 +++ drivers/scsi/osd/Makefile | 37 +++ drivers/scsi/osd/osd_debug.h | 27 +++ drivers/scsi/osd/osd_initiator.c | 448 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 538 insertions(+), 0 deletions(-) create mode 100644 drivers/scsi/osd/Kbuild create mode 100755 drivers/scsi/osd/Makefile create mode 100644 drivers/scsi/osd/osd_debug.h create mode 100644 drivers/scsi/osd/osd_initiator.c diff --git a/drivers/scsi/osd/Kbuild b/drivers/scsi/osd/Kbuild new file mode 100644 index 0000000..b6328e6 --- /dev/null +++ b/drivers/scsi/osd/Kbuild @@ -0,0 +1,26 @@ +# +# Kbuild for the OSD modules +# +# Copyright (C) 2008 Panasas Inc. All rights reserved. +# +# Authors: +# Boaz Harrosh <bharrosh@panasas.com> +# Benny Halevy <bhalevy@panasas.com> +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License version 2 +# + +ifneq ($(OSD_INC),) +# we are built out-of-tree Kconfigure everything as on + +CONFIG_SCSI_OSD_INITIATOR=m +ccflags-y += -DCONFIG_SCSI_OSD_INITIATOR -DCONFIG_SCSI_OSD_INITIATOR_MODULE + +ccflags-y += -I$(OSD_INC) +# ccflags-y += -DCONFIG_SCSI_OSD_DEBUG +endif + +# libosd.ko - osd-initiator library +libosd-y := osd_initiator.o +obj-$(CONFIG_SCSI_OSD_INITIATOR) += libosd.o diff --git a/drivers/scsi/osd/Makefile b/drivers/scsi/osd/Makefile new file mode 100755 index 0000000..d905344 --- /dev/null +++ b/drivers/scsi/osd/Makefile @@ -0,0 +1,37 @@ +# +# Makefile for the OSD modules (out of ...
Kconfig file for the drivers/scsi/osd subdirectory. Adds the following config items: config SCSI_OSD_INITIATOR config SCSI_OSD_ULD config SCSI_OSD_DEBUG Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Reviewed-by: Benny Halevy <bhalevy@panasas.com> --- drivers/scsi/osd/Kconfig | 41 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 41 insertions(+), 0 deletions(-) create mode 100644 drivers/scsi/osd/Kconfig diff --git a/drivers/scsi/osd/Kconfig b/drivers/scsi/osd/Kconfig new file mode 100644 index 0000000..ac3be8a --- /dev/null +++ b/drivers/scsi/osd/Kconfig @@ -0,0 +1,41 @@ +# +# Kernel configuration file for the OSD scsi protocol +# +# Copyright (C) 2008 Panasas Inc. All rights reserved. +# +# Authors: +# Boaz Harrosh <bharrosh@panasas.com> +# Benny Halevy <bhalevy@panasas.com> +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public version 2 License as +# published by the Free Software Foundation +# +# FIXME: SCSI_OSD_INITIATOR should select CONFIG (HMAC) SHA1 somehow. +# How is it done properly? +# + +config SCSI_OSD_INITIATOR + tristate "OSD-Initiator library" + depends on SCSI + help + Enable the OSD-Initiator library (libosd.ko). + NOTE: You must also select CRYPTO_SHA1 + CRYPTO_HMAC and their + dependencies + +config SCSI_OSD_ULD + tristate "OSD Upper Level driver" + depends on SCSI_OSD_INITIATOR + help + Build a SCSI upper layer driver that exports /dev/osdX devices + to user-mode for testing and controlling OSD devices. It is also + needed by osdfs, for mounting an OSD based file system. + +config SCSI_OSD_DEBUG + bool "Compile All OSD modules with lots of DEBUG prints" + default n + depends on SCSI_OSD_INITIATOR + help + OSD Code is populated with lots of OSD_DEBUG(..) printouts to + dmesg. Enable this if you found a bug and you want to help us + track the problem (see also MAINTAINERS). -- 1.6.0.1 --
OSD in kernel source code is assumed to be at: drivers/scsi/osd/ with its own Makefile and Kconfig Add includes to them from drivers/scsi Makefile and Kconfig Add OSD to MAINTAINERS file Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Reviewed-by: Benny Halevy <bhalevy@panasas.com> --- MAINTAINERS | 10 ++++++++++ drivers/scsi/Kconfig | 2 ++ drivers/scsi/Makefile | 2 ++ 3 files changed, 14 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 355c192..03da1e7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3153,6 +3153,16 @@ L: orinoco-devel@lists.sourceforge.net W: http://www.nongnu.org/orinoco/ S: Maintained +OSD LIBRARY +P: Boaz Harrosh +M: bharrosh@panasas.com +P: Benny Halevy +M: bhalevy@panasas.com +L: osd-dev@open-osd.org +W: http://open-osd.org +T: git://git.open-osd.org/osd-lib.git +S: Maintained + P54 WIRELESS DRIVER P: Michael Wu M: flamingice@sourmilk.net diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 403ecad..e6af21c 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -1780,4 +1780,6 @@ source "drivers/scsi/pcmcia/Kconfig" source "drivers/scsi/device_handler/Kconfig" +source "drivers/scsi/osd/Kconfig" + endmenu diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index 72fd504..1e49632 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -135,6 +135,8 @@ obj-$(CONFIG_CHR_DEV_SG) += sg.o obj-$(CONFIG_CHR_DEV_SCH) += ch.o obj-$(CONFIG_SCSI_ENCLOSURE) += ses.o +obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/ + # This goes last, so that "real" scsi devices probe earlier obj-$(CONFIG_SCSI_DEBUG) += scsi_debug.o -- 1.6.0.1 --
Add support for OSD2 at run time. It is now possible to run with
both OSDv1 and OSDv2 targets at the same time. The actual detection
should be preformed by the security manager, as the version is encoded
in the capability structure.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
drivers/scsi/osd/osd_initiator.c | 94 ++++++++++++++++++++++++++++++++------
include/scsi/osd_initiator.h | 39 ++++++++++++++++
include/scsi/osd_protocol.h | 86 +++++++++++++++++++++++++++++++++--
3 files changed, 201 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
index 567a2c6..9127fc4 100644
--- a/drivers/scsi/osd/osd_initiator.c
+++ b/drivers/scsi/osd/osd_initiator.c
@@ -57,36 +57,50 @@ static inline void build_test(void)
{
/* structures were not packed */
BUILD_BUG_ON(sizeof(struct osd_capability) != OSD_CAP_LEN);
+ BUILD_BUG_ON(sizeof(struct osdv2_cdb) != OSD_TOTAL_CDB_LEN);
BUILD_BUG_ON(sizeof(struct osdv1_cdb) != OSDv1_TOTAL_CDB_LEN);
}
static unsigned _osd_req_cdb_len(struct osd_request *or)
{
- return OSDv1_TOTAL_CDB_LEN;
+ return osd_req_is_ver1(or) ? OSDv1_TOTAL_CDB_LEN : OSD_TOTAL_CDB_LEN;
}
static unsigned _osd_req_alist_elem_size(struct osd_request *or, unsigned len)
{
- return osdv1_attr_list_elem_size(len);
+ return osd_req_is_ver1(or) ?
+ osdv1_attr_list_elem_size(len) :
+ osdv2_attr_list_elem_size(len);
}
static unsigned _osd_req_alist_size(struct osd_request *or, void *list_head)
{
- return osdv1_list_size(list_head);
+ return osd_req_is_ver1(or) ?
+ osdv1_list_size(list_head) :
+ osdv2_list_size(list_head);
}
static unsigned _osd_req_sizeof_alist_header(struct osd_request *or)
{
- return sizeof(struct osdv1_attributes_list_header);
+ return osd_req_is_ver1(or) ?
+ sizeof(struct osdv1_attributes_list_header) :
+ sizeof(struct osdv2_attributes_list_header);
}
static void ...Most simple user-app to invoke the in-kernel test ioctl of the specified osd device. Usage: osd_test "/dev/osdX" Where /dev/osdX is the osd device (lun) to run tests on. The output of the tests is in dmesg log file Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> --- drivers/scsi/osd/Makefile | 10 +++++- drivers/scsi/osd/osd_test.c | 74 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 82 insertions(+), 2 deletions(-) create mode 100644 drivers/scsi/osd/osd_test.c diff --git a/drivers/scsi/osd/Makefile b/drivers/scsi/osd/Makefile index d905344..92d8b19 100755 --- a/drivers/scsi/osd/Makefile +++ b/drivers/scsi/osd/Makefile @@ -28,10 +28,16 @@ V ?= 0 # this is the basic Kbuild out-of-tree invocation, with the M= option KBUILD_BASE = +$(MAKE) -C $(KSRC) M=`pwd` KBUILD_OUTPUT=$(KBUILD_OUTPUT) ARCH=$(ARCH) V=$(V) -all: libosd +all: libosd osd_test libosd: ; $(KBUILD_BASE) OSD_INC=$(OSD_INC) modules -clean: +clean: osd_test_clean $(KBUILD_BASE) clean + +osd_test: osd_test.o + $(CC) -o $@ $< + +osd_test_clean: + rm -vf osd_test diff --git a/drivers/scsi/osd/osd_test.c b/drivers/scsi/osd/osd_test.c new file mode 100644 index 0000000..dc74865 --- /dev/null +++ b/drivers/scsi/osd/osd_test.c @@ -0,0 +1,74 @@ +/* + * osd_test.c - A user-mode program that calls into the osd ULD + * + * Copyright (C) 2008 Panasas Inc. All rights reserved. + * + * Authors: + * Boaz Harrosh <bharrosh@panasas.com> + * Benny Halevy <bhalevy@panasas.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must ...
Auto detect an OSDv2 or OSDv1 target at run time. Note how none
of the OSD API calls change. The tests do not know what device
version it is.
This test now passes against both the IBM-OSD-SIM OSD1 target
as well as OSC's OSD2 target.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
drivers/scsi/osd/osd_initiator.c | 125 ++++++++++++++++++++++++++++++++++++++
drivers/scsi/osd/osd_uld.c | 5 ++
include/scsi/osd_initiator.h | 3 +
3 files changed, 133 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
index 9127fc4..8e59cdc 100644
--- a/drivers/scsi/osd/osd_initiator.c
+++ b/drivers/scsi/osd/osd_initiator.c
@@ -41,6 +41,7 @@
#include <scsi/osd_initiator.h>
#include <scsi/osd_sec.h>
+#include <scsi/osd_attributes.h>
#include <scsi/scsi_device.h>
#include "osd_debug.h"
@@ -61,6 +62,130 @@ static inline void build_test(void)
BUILD_BUG_ON(sizeof(struct osdv1_cdb) != OSDv1_TOTAL_CDB_LEN);
}
+static char *_osd_ver_desc(struct osd_request *or)
+{
+ return osd_req_is_ver1(or) ? "OSD1" : "OSD2";
+}
+
+#define ATTR_DEF_RI(id, len) ATTR_DEF(OSD_APAGE_ROOT_INFORMATION, id, len)
+
+static int _osd_print_system_info(struct osd_dev *od, void *caps)
+{
+ struct osd_request *or;
+ struct osd_attr get_attrs[] = {
+ ATTR_DEF_RI(OSD_ATTR_RI_VENDOR_IDENTIFICATION, 8),
+ ATTR_DEF_RI(OSD_ATTR_RI_PRODUCT_IDENTIFICATION, 16),
+ ATTR_DEF_RI(OSD_ATTR_RI_PRODUCT_MODEL, 32),
+ ATTR_DEF_RI(OSD_ATTR_RI_PRODUCT_REVISION_LEVEL, 4),
+ ATTR_DEF_RI(OSD_ATTR_RI_PRODUCT_SERIAL_NUMBER, 64 /*variable*/),
+ ATTR_DEF_RI(OSD_ATTR_RI_OSD_NAME, 64 /*variable*/),
+ ATTR_DEF_RI(OSD_ATTR_RI_TOTAL_CAPACITY, 8),
+ ATTR_DEF_RI(OSD_ATTR_RI_USED_CAPACITY, 8),
+ ATTR_DEF_RI(OSD_ATTR_RI_NUMBER_OF_PARTITIONS, 8),
+ ATTR_DEF_RI(OSD_ATTR_RI_CLOCK, 6),
+ /* IBM-OSD-SIM Has a bug with this one put it last */
+ ATTR_DEF_RI(OSD_ATTR_RI_OSD_SYSTEM_ID, ...Layout the signing of OSD's CDB and all-data security modes. The actual
code for signing the data and CDB is missing, but the code flow and the extra
buffer segments are all in place.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
drivers/scsi/osd/osd_initiator.c | 85 ++++++++++++++++++++++++++++++++++++++
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
index da0c53c..2ed0429 100644
--- a/drivers/scsi/osd/osd_initiator.c
+++ b/drivers/scsi/osd/osd_initiator.c
@@ -109,6 +109,14 @@ static osd_cdb_offset osd_req_encode_offset(struct osd_request *or,
OSDv1_OFFSET_MIN_SHIFT, OSD_OFFSET_MAX_SHIFT);
}
+static struct osd_security_parameters *
+_osd_req_sec_params(struct osd_request *or)
+{
+ struct osd_cdb *ocdb = &or->cdb;
+
+ return &ocdb->v1.sec_params;
+}
+
void osd_dev_init(struct osd_dev *osdd, struct scsi_device *scsi_dev)
{
memset(osdd, 0, sizeof(*osdd));
@@ -796,6 +804,64 @@ int _osd_req_finalize_attr_page(struct osd_request *or)
return ret;
}
+int _osd_req_finalize_data_integrity(struct osd_request *or,
+ bool has_in, bool has_out, const u8 *cap_key)
+{
+ struct osd_security_parameters *sec_parms = _osd_req_sec_params(or);
+ int ret;
+
+ if (!osd_is_sec_alldata(sec_parms))
+ return 0;
+
+ if (has_out) {
+ struct _osd_req_data_segment seg = {
+ .buff = &or->out_data_integ,
+ .total_bytes = sizeof(or->out_data_integ),
+ };
+ int pad;
+
+ or->out_data_integ.data_bytes = cpu_to_be64(
+ or->out.bio ? or->out.bio->bi_size : 0);
+ or->out_data_integ.set_attributes_bytes = cpu_to_be64(
+ or->set_attr.total_bytes);
+ or->out_data_integ.get_attributes_bytes = cpu_to_be64(
+ or->enc_get_attr.total_bytes);
+
+ sec_parms->data_out_integrity_check_offset =
+ osd_req_encode_offset(or, or->out.total_bytes, &pad);
+
+ ret = _req_append_segment(or, pad, &seg, or->out.last_seg,
+ ...Some commands declared in header are not yet implemented. Put them
as stubs in .c file, just so they take their place in the file
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
drivers/scsi/osd/osd_initiator.c | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
index 23f7e95..567a2c6 100644
--- a/drivers/scsi/osd/osd_initiator.c
+++ b/drivers/scsi/osd/osd_initiator.c
@@ -341,6 +341,9 @@ static void _osd_req_encode_common(struct osd_request *or,
/*
* Device commands
*/
+/*TODO: void osd_req_set_master_seed_xchg(struct osd_request *, ...); */
+/*TODO: void osd_req_set_master_key(struct osd_request *, ...); */
+
void osd_req_format(struct osd_request *or, u64 tot_capacity)
{
_osd_req_encode_common(or, OSD_ACT_FORMAT_OSD, &osd_root_object, 0,
@@ -371,6 +374,10 @@ void osd_req_flush_obsd(struct osd_request *or,
}
EXPORT_SYMBOL(osd_req_flush_obsd);
+/*TODO: void osd_req_perform_scsi_command(struct osd_request *,
+ const u8 *cdb, ...); */
+/*TODO: void osd_req_task_management(struct osd_request *, ...); */
+
/*
* Partition commands
*/
@@ -397,6 +404,10 @@ void osd_req_remove_partition(struct osd_request *or, osd_id partition)
}
EXPORT_SYMBOL(osd_req_remove_partition);
+/*TODO: void osd_req_set_partition_key(struct osd_request *,
+ osd_id partition, u8 new_key_id[OSD_CRYPTO_KEYID_SIZE],
+ u8 seed[OSD_CRYPTO_SEED_SIZE]); */
+
static int _osd_req_list_objects(struct osd_request *or,
__be16 action, const struct osd_obj_id *obj, osd_id initial_id,
struct osd_obj_id_list *list, unsigned nelem)
@@ -462,6 +473,11 @@ EXPORT_SYMBOL(osd_req_flush_partition);
/*
* Collection commands
*/
+/*TODO: void osd_req_create_collection(struct osd_request *,
+ const struct osd_obj_id *); */
+/*TODO: void osd_req_remove_collection(struct osd_request *,
+ const struct osd_obj_id ...Add a Linux driver module that registers as a SCSI ULD and probes for OSD type SCSI devices. When an OSD-type SCSI device is found a character device is created in the form of /dev/osdX - where X goes from 0 up to hard coded 64. The Major character device number used is *260*, which is free (as of Linux v2.6.28-rc3). A single ioctl is currently supported that will invoke an in-kernel test on the specified OSD device (lun). Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Reviewed-by: Benny Halevy <bhalevy@panasas.com> --- drivers/scsi/osd/Kbuild | 7 + drivers/scsi/osd/osd_ktests.h | 27 +++ drivers/scsi/osd/osd_uld.c | 388 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 422 insertions(+), 0 deletions(-) create mode 100644 drivers/scsi/osd/osd_ktests.h create mode 100644 drivers/scsi/osd/osd_uld.c diff --git a/drivers/scsi/osd/Kbuild b/drivers/scsi/osd/Kbuild index b4678e0..f39f82f 100644 --- a/drivers/scsi/osd/Kbuild +++ b/drivers/scsi/osd/Kbuild @@ -17,6 +17,9 @@ ifneq ($(OSD_INC),) CONFIG_SCSI_OSD_INITIATOR=m EXTRA_CFLAGS += -DCONFIG_SCSI_OSD_INITIATOR -DCONFIG_SCSI_OSD_INITIATOR_MODULE +CONFIG_SCSI_OSD_ULD=m +EXTRA_CFLAGS += -DCONFIG_SCSI_OSD_ULD -DCONFIG_SCSI_OSD_ULD_MODULE + EXTRA_CFLAGS += -I$(OSD_INC) # EXTRA_CFLAGS += -DCONFIG_SCSI_OSD_DEBUG @@ -24,3 +27,7 @@ endif libosd-objs := osd_initiator.o obj-$(CONFIG_SCSI_OSD_INITIATOR) += libosd.o + +# osd.ko - SCSI ULD and char-device +osd-objs := osd_uld.o +obj-$(CONFIG_SCSI_OSD_ULD) += osd.o diff --git a/drivers/scsi/osd/osd_ktests.h b/drivers/scsi/osd/osd_ktests.h new file mode 100644 index 0000000..a9e5e00 --- /dev/null +++ b/drivers/scsi/osd/osd_ktests.h @@ -0,0 +1,27 @@ +/* + * osd_ktests.h - Define the ktests.c API + * + * Copyright (C) 2008 Panasas Inc. All rights reserved. + * + * Authors: + * Boaz Harrosh <bharrosh@panasas.com> + * Benny Halevy <bhalevy@panasas.com> + * + * This program is free software; you can redistribute it and/or ...
Add support for the various List-objects commands. List-partitions-in-device,
List-collections-in-partition, List-objects-in-partition,
List-objects-in-collection. All these support partial listing and continuation.
Add support for the different Flush commands and options.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
drivers/scsi/osd/osd_initiator.c | 124 ++++++++++++++++++++++++++++++++++++++
1 files changed, 124 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
index 2ed0429..23f7e95 100644
--- a/drivers/scsi/osd/osd_initiator.c
+++ b/drivers/scsi/osd/osd_initiator.c
@@ -102,6 +102,16 @@ static bool _osd_req_is_alist_type(struct osd_request *or,
}
}
+/* This is for List-objects not Attributes-Lists */
+static void _osd_req_encode_olist(struct osd_request *or,
+ struct osd_obj_id_list *list)
+{
+ struct osd_cdb_head *cdbh = osd_cdb_head(&or->cdb);
+
+ cdbh->v1.list_identifier = list->list_identifier;
+ cdbh->v1.start_address = list->continuation_id;
+}
+
static osd_cdb_offset osd_req_encode_offset(struct osd_request *or,
u64 offset, unsigned *padding)
{
@@ -338,6 +348,29 @@ void osd_req_format(struct osd_request *or, u64 tot_capacity)
}
EXPORT_SYMBOL(osd_req_format);
+int osd_req_list_dev_partitions(struct osd_request *or,
+ osd_id initial_id, struct osd_obj_id_list *list, unsigned nelem)
+{
+ return osd_req_list_partition_objects(or, 0, initial_id, list, nelem);
+}
+EXPORT_SYMBOL(osd_req_list_dev_partitions);
+
+static void _osd_req_encode_flush(struct osd_request *or,
+ enum osd_options_flush_scope_values op)
+{
+ struct osd_cdb_head *ocdb = osd_cdb_head(&or->cdb);
+
+ ocdb->command_specific_options = op;
+}
+
+void osd_req_flush_obsd(struct osd_request *or,
+ enum osd_options_flush_scope_values op)
+{
+ _osd_req_encode_common(or, OSD_ACT_FLUSH_OSD, &osd_root_object, 0, 0);
+ _osd_req_encode_flush(or, ...Currently testing what is implemented in the osd_initiator library. That is - format, create/remove partition, create/remove object, read and write to objects. This test passes against the IBM-OSD-SIM OSDv1 target. Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Reviewed-by: Benny Halevy <bhalevy@panasas.com> --- drivers/scsi/osd/Kbuild | 2 +- drivers/scsi/osd/osd_ktests.c | 331 +++++++++++++++++++++++++++++++++++++++++ drivers/scsi/osd/osd_ktests.h | 4 + drivers/scsi/osd/osd_uld.c | 2 +- 4 files changed, 337 insertions(+), 2 deletions(-) create mode 100644 drivers/scsi/osd/osd_ktests.c diff --git a/drivers/scsi/osd/Kbuild b/drivers/scsi/osd/Kbuild index f39f82f..da00ddb 100644 --- a/drivers/scsi/osd/Kbuild +++ b/drivers/scsi/osd/Kbuild @@ -29,5 +29,5 @@ libosd-objs := osd_initiator.o obj-$(CONFIG_SCSI_OSD_INITIATOR) += libosd.o # osd.ko - SCSI ULD and char-device -osd-objs := osd_uld.o +osd-objs := osd_uld.o osd_ktests.o obj-$(CONFIG_SCSI_OSD_ULD) += osd.o diff --git a/drivers/scsi/osd/osd_ktests.c b/drivers/scsi/osd/osd_ktests.c new file mode 100644 index 0000000..f620915 --- /dev/null +++ b/drivers/scsi/osd/osd_ktests.c @@ -0,0 +1,331 @@ +/* + * osd_ktests.c - An osd_initiator library in-kernel test suite + * called by the osd_uld module + * + * Copyright (C) 2008 Panasas Inc. All rights reserved. + * + * Authors: + * Boaz Harrosh <bharrosh@panasas.com> + * Benny Halevy <bhalevy@panasas.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above ...
Add tests for setting/getting Attribute lists. All combinations
of read/write with set/get attributes are tested.
(6 possibilities), So all but data integrity request structure
layouts are attempted.
This test passes against the IBM-OSD-SIM OSDv1 target.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
drivers/scsi/osd/osd_ktests.c | 110 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/osd/osd_ktests.c b/drivers/scsi/osd/osd_ktests.c
index f620915..f0a791f 100644
--- a/drivers/scsi/osd/osd_ktests.c
+++ b/drivers/scsi/osd/osd_ktests.c
@@ -43,6 +43,7 @@
#include <scsi/osd_initiator.h>
#include <scsi/osd_sec.h>
+#include <scsi/osd_attributes.h>
#include "osd_ktests.h"
#include "osd_debug.h"
@@ -260,6 +261,91 @@ int ktest_remove_par(struct osd_dev *osd_dev)
return 0;
}
+int ktest_write_read_attr(struct osd_dev *osd_dev, void *buff,
+ bool doread, bool doset, bool doget)
+{
+ struct request_queue *req_q = osd_dev->scsi_dev->request_queue;
+ struct osd_request *or;
+ char g_caps[OSD_CAP_LEN];
+ int ret;
+ struct bio *bio;
+ char *domsg;
+ /* set attrs */
+ static char name[] = "ktest_write_read_attr";
+ __be64 max_len = cpu_to_be64(0x80000000L);
+ struct osd_obj_id obj = {
+ .partition = first_par_id,
+ .id = first_obj_id,
+ };
+ struct osd_attr set_attrs[] = {
+ ATTR_SET(OSD_APAGE_OBJECT_QUOTAS, OSD_ATTR_OQ_MAXIMUM_LENGTH,
+ sizeof(max_len), &max_len),
+ ATTR_SET(OSD_APAGE_OBJECT_INFORMATION, OSD_ATTR_OI_USERNAME,
+ sizeof(name), name),
+ };
+ struct osd_attr get_attrs[] = {
+ ATTR_DEF(OSD_APAGE_OBJECT_INFORMATION,
+ OSD_ATTR_OI_USED_CAPACITY, sizeof(__be64)),
+ ATTR_DEF(OSD_APAGE_OBJECT_INFORMATION,
+ OSD_ATTR_OI_LOGICAL_LENGTH, sizeof(__be64)),
+ };
+
+ KTEST_START_REQ(osd_dev, or);
+ bio = bio_map_kern(req_q, buff, BUFF_SIZE, GFP_KERNEL);
+ if (!bio) {
+ OSD_ERR("!!! Failed to allocate ...Support for both List-Mode and Page-Mode osd attributes. One of
these operations may be added to most other operations.
Define the OSD standard's attribute pages constants and structures
(osd_attributes.h)
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Reviewed-by: Benny Halevy <bhalevy@panasas.com>
---
drivers/scsi/osd/osd_initiator.c | 573 ++++++++++++++++++++++++++++++++++++++
include/scsi/osd_attributes.h | 327 ++++++++++++++++++++++
2 files changed, 900 insertions(+), 0 deletions(-)
create mode 100644 include/scsi/osd_attributes.h
diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
index 33450b8..da0c53c 100644
--- a/drivers/scsi/osd/osd_initiator.c
+++ b/drivers/scsi/osd/osd_initiator.c
@@ -65,6 +65,50 @@ static unsigned _osd_req_cdb_len(struct osd_request *or)
return OSDv1_TOTAL_CDB_LEN;
}
+static unsigned _osd_req_alist_elem_size(struct osd_request *or, unsigned len)
+{
+ return osdv1_attr_list_elem_size(len);
+}
+
+static unsigned _osd_req_alist_size(struct osd_request *or, void *list_head)
+{
+ return osdv1_list_size(list_head);
+}
+
+static unsigned _osd_req_sizeof_alist_header(struct osd_request *or)
+{
+ return sizeof(struct osdv1_attributes_list_header);
+}
+
+static void _osd_req_set_alist_type(struct osd_request *or,
+ void *list, int list_type)
+{
+ struct osdv1_attributes_list_header *attr_list = list;
+
+ memset(attr_list, 0, sizeof(*attr_list));
+ attr_list->type = list_type;
+}
+
+static bool _osd_req_is_alist_type(struct osd_request *or,
+ void *list, int list_type)
+{
+ if (!list)
+ return false;
+
+ if (1) {
+ struct osdv1_attributes_list_header *attr_list = list;
+
+ return attr_list->type == list_type;
+ }
+}
+
+static osd_cdb_offset osd_req_encode_offset(struct osd_request *or,
+ u64 offset, unsigned *padding)
+{
+ return __osd_encode_offset(offset, padding,
+ OSDv1_OFFSET_MIN_SHIFT, OSD_OFFSET_MAX_SHIFT);
+}
+
void osd_dev_init(struct osd_dev *osdd, struct ...Add osd.txt to Documentation/scsi/ Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Reviewed-by: Benny Halevy <bhalevy@panasas.com> --- Documentation/scsi/osd.txt | 198 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 198 insertions(+), 0 deletions(-) create mode 100644 Documentation/scsi/osd.txt diff --git a/Documentation/scsi/osd.txt b/Documentation/scsi/osd.txt new file mode 100644 index 0000000..a6735ae --- /dev/null +++ b/Documentation/scsi/osd.txt @@ -0,0 +1,198 @@ +The OSD Standard +================ +OSD (Object-Based Storage Device) is a T10 SCSI command set that is designed +to provide efficient operation of input/output logical units that manage the +allocation, placement, and accessing of variable-size data-storage containers, +called objects. Objects are intended to contain operating system and application +constructs. Each object has associated attributes attached to it, which are +integral part of the object and provide metadata about the object. The standard +defines some common obligatory attributes, but user attributes can be added as +needed. + +See: http://www.t10.org/ftp/t10/drafts/osd2/ for the latest draft for OSD 2 +or search the web for "OSD SCSI" + +OSD in the Linux Kernel +======================= +osd-initiator: + The main component of OSD in Kernel is the osd-initiator library. Its main +user is intended to be the pNFS-over-objects layout driver, which uses objects +as its back-end data storage. Other clients are the other osd parts listed below. + +osd-uld: + This is a SCSI ULD that registers for OSD type devices and provides a testing +platform, both for the in-kernel initiator as well as connected targets. It +currently has no useful user-mode API, though it could have if need be. + +osdfs: + Is an OSD based Linux file system. It uses the osd-initiator and osd-uld, +to export a usable file system for users. +See Documentation/filesystems/osdfs.txt for more details + +osd target: + There are no current plans ...
Kernel clients like osdfs can retrieve struct osd_dev(s)
by means of below API.
+ osduld_path_lookup() - given a path (e.g "/dev/osd0") locks and
returns the corresponding struct osd_dev, which is then needed
for subsequent libosd use.
+ osduld_put_device() - free up use of an osd_dev.
Devices can be shared by multiple clients. The osd_uld_device's
life time is governed by an embedded kref structure.
The osd_uld_device holds an extra reference to both it's
char-device and it's scsi_device, and will release these just
before the final deallocation.
There are three possible lock sources of the osd_uld_device
1. First and for most is the probe() function called by
scsi-ml upon a successful login into a target. Released in release()
when logout.
2. Second by user-mode file handles opened on the char-dev.
3. Third is here by Kernel users.
All three locks must be removed before the osd_uld_device is freed.
The MODULE has three lock sources as well:
1. scsi-ml at probe() time, removed after release(). (login/logout)
2. The user-mode file handles open/close.
3. Import symbols by client modules like osdfs.
TODO:
This API is not enough for the pNFS-objects LD. A more versatile
API will be needed. Proposed API could be:
struct osd_dev *osduld_sysid_lookup(const char id[OSD_SYSTEMID_LEN]);
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
---
drivers/scsi/osd/osd_uld.c | 52 ++++++++++++++++++++++++++++++++++++++++++
include/scsi/osd_initiator.h | 5 ++++
2 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/osd/osd_uld.c b/drivers/scsi/osd/osd_uld.c
index 87b4540..0229301 100644
--- a/drivers/scsi/osd/osd_uld.c
+++ b/drivers/scsi/osd/osd_uld.c
@@ -42,6 +42,7 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include <linux/namei.h>
#include <linux/cdev.h>
#include <linux/fs.h>
#include <linux/module.h>
@@ -142,6 +143,57 @@ static const struct file_operations osd_fops = {
.unlocked_ioctl = ...We need a major for a char device for our OSD device driver. Attached is a proposed patch for the Documentation/devices.txt and include/linux/major.h files. I have allocated the *260* char device as it looked like the next available on the lanana.org web-site (http://lanana.org/docs/device-list/devices-2.6+.txt) Any number will do. Please allocate a number for us (See http:/open-osd.org for further information) Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> CC: Torben Mathiasen <device@lanana.org> --- Documentation/devices.txt | 6 ++++++ include/linux/major.h | 1 + 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 05c8064..d18070b 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -3142,6 +3142,12 @@ Your cooperation is appreciated. 1 = /dev/blockrom1 Second ROM card's translation layer interface ... +260 char OSD (Object-based-device) SCSI Device + 0 = /dev/osd0 First OSD Device + 1 = /dev/osd1 Second OSD Device + ... + 255 = /dev/osd255 256th OSD Device + **** ADDITIONAL /dev DIRECTORY ENTRIES This section details additional entries that should or may exist in diff --git a/include/linux/major.h b/include/linux/major.h index 8824945..058ec15 100644 --- a/include/linux/major.h +++ b/include/linux/major.h @@ -171,5 +171,6 @@ #define VIOTAPE_MAJOR 230 #define BLOCK_EXT_MAJOR 259 +#define SCSI_OSD_MAJOR 260 /* open-osd's OSD scsi device */ #endif -- 1.6.0.1 --
Hi Torben Mathiasen The maintainers file as well as the lanana.org website only states this <device@lanana.org> email address. I hope it is the right one. Please you have not confirmed or revoked my ability to use 260 as a Major for a new char-device. Please review What git tree should this go through? Thanks --
Was it cc-ed to device@lanana.org? I can't see that. Adding it now. John Cagle, can you comment on this, please? And also have the attached patch merged into the MAINTAINERS file, please. The www.lanana.org web page also needs to be updated: Maintained by Torben Mathiasen -- ~Randy
On Tue, 04 Nov 2008 18:09:31 +0200 The best way to do that is to include your git tree in linux-next. If this code has a probably-will-be-merged-in-2.6.29 status then please prepare a branch for Stephen to include in the linux-next lineup. --
Thanks Andrew I was thinking this code would eventually go into Linux-next threw James tree. But thought if there was a way for some exposure, so to give James some confidence in the code before he commits to it. But this way it could be perfect, thanks. Stephen Hi I have just that branch ready it is: git://git.open-osd.org/linux-open-osd.git osd Note the "osd" branch. Do I need to call it something special like "linux-next"? (Give me 24 hours to fix all current comments) Also one more question. This tree is based on latest scsi-misc-2.6.git, Because it is destined to go threw James tree at the end. Do I need to prepare a special tree based on Linus-latest? Thanks in advance Boaz --
Hi Stephen and James
I have prepared a branch for linux-next based on today's Linus tree
It is here:
git://git.open-osd.org/linux-open-osd.git linux-next
This is if it's OK with James, as these bits are his responsibility.
They need only sit in linux-next for a couple of weeks to get some wider
compilation exposure. Other then that they are totally new code and
are safe. Eventually they should be included into Linux-next through
scsi-misc-2.6.
I have only posted "ver 2" updates to a couple of patches that had
comments by people but more patches changed. Mainly:
- rename of scsi_dev => scsi_device
- missing static keyword
- Kbuild fixes and comments by Sam Ravnborg
- small typos found on the way
The new patchset can be reviewed at:
git://git.open-osd.org/linux-open-osd.git linux-next
http://git.open-osd.org/gitweb.cgi?p=linux-open-osd.git;a=shortlog;h=linux-next
or Based on current scsi-misc-2.6:
git://git.open-osd.org/linux-open-osd.git osd
http://git.open-osd.org/gitweb.cgi?p=linux-open-osd.git;a=shortlog;h=osd
I did not want to spam the mailing-list with somewhat same patches.
I will post them, if any one needs me to.
Thanks everyone for your help
Boaz
--
Hi Boaz, On Sun, 09 Nov 2008 16:58:59 +0200 Boaz Harrosh <bharrosh@panasas.com> wrot= I have added that tree to linux-next for today. What I say to everyone: commits in that branch must have been posted somewhere appropriate, reviewed, unit tested and destined for the next merge window. Also, note that my (new) practise is to temporarily drop a tree if it causes non-trivial conflicts (especially with Linus' tree), so don't be too upset if you get a message from me to that effect. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Thank you Stephen, very much This has proven itself already. I found some warnings on some ARCHs concerning printk of u64 types. I have made a sweep and fixed all these places and others. (same place: git://git.open-osd.org/linux-open-osd.git linux-next) If you could keep it for the next round it could be grate. So I can make sure I got rid of all the warnings. Thanks again Boaz --
Hi Boaz, On Mon, 10 Nov 2008 14:52:21 +0200 Boaz Harrosh <bharrosh@panasas.com> wrot= Good. That's partly what -next is for (to find the arch dependent Normally trees stay in linux-next until they are no longer needed (usually at least until they have been integrated into Linus' tree) and I automatically refetch the trees each day. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
| Jesse Barnes | Re: [stable] [BUG][PATCH] cpqphp: fix kernel NULL pointer dereference |
| Greg KH | [003/136] p54usb: add Zcomax XG-705A usbid |
| Magnus Damm | [PATCH 03/07] ARM: Use shared GIC entry macros on Realview |
| Oliver Neukum | Re: [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30 |
| Martin Schwidefsky | Re: [PATCH] optimized ktime_get[_ts] for GENERIC_TIME=y |
git: | |
| Junio C Hamano | Re: Some advanced index playing |
| Jeff King | Re: confusion over the new branch and merge config |
| Robin Rosenberg | Re: cvs2svn conversion directly to git ready for experimentation |
| Linus Torvalds | git binary size... |
| Ævar Arnfjörð Bjarmason | Re: Challenge with Git-Bash |
| Linux Kernel Mailing List | md: move allocation of ->que |