[patch 1/8] staging: visorutil driver to provide common functionality to other s-Par drivers

[Romer, Benjamin M]

Hi Greg, 

The copyright text is old boilerplate that we'd been carrying.  We'll
change it so that it's correctly GPL 2 only, and we'll fix all of the
EXPORT_SYMBOL()s also.

The majority of our proc entries are switches for debugging or purely
informational, so these could be moved to /sys with little trouble. The
only user space program that would care about them is our guest
installation software, and we at Unisys can easily update that when the
API changes.

-- Ben

-----Original Message-----
From: Greg KH <gregkh at linuxfoundation.org>
To: Ken Cox <jkc at redhat.com>
Subject: Re: [patch 1/8] staging: visorutil driver to provide common
functionality to other s-Par drivers
Date: Mon, 3 Mar 2014 11:15:13 -0800

On Mon, Mar 03, 2014 at 11:30:19AM -0600, Ken Cox wrote:
> +/* periodic_work.h
> + *
> + * Copyright © 2010 - 2013 UNISYS CORPORATION
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or (at
> + * your option) any later version.

I have to ask, do you really mean "any later version" here?

> +CHARQUEUE *charqueue_create(ulong nslots)
> +{
> +    int alloc_size = sizeof(CHARQUEUE) + nslots + 1;
> +    CHARQUEUE *cq = kmalloc(alloc_size, GFP_KERNEL|__GFP_NORETRY);
> +    if (cq == NULL) {
> +        ERRDRV("charqueue_create allocation failed (alloc_size=%d)",
> +               alloc_size);
> +        return NULL;
> +    }
> +    cq->alloc_size = alloc_size;
> +    cq->nslots = nslots;
> +    cq->head = cq->tail = 0;
> +    spin_lock_init(&cq->lock);
> +    return cq;
> +}
> +EXPORT_SYMBOL(charqueue_create);

For staging drivers, I really want to see EXPORT_SYMBOL_GPL() for the
exports for a variety of reasons dealing with historical issues...

Can you change all of these please?

And how "wed" are you to the proc interface, that is going to change,
right?  What userspace tools rely on it and who is going to be
responsible for changing them as the user/kernel api changes with this
code?

thanks,
g
greg k-h

-- 
Ben Romer | Software Engineer |
Virtual Systems Development 

Unisys Corporation |  2476
Swedesford Rd |  Malvern, PA 19355
|  610-648-7140