lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110823230106.GJ9641@kroah.com>
Date:	Tue, 23 Aug 2011 16:01:06 -0700
From:	Greg KH <greg@...ah.com>
To:	"K. Y. Srinivasan" <kys@...rosoft.com>
Cc:	gregkh@...e.de, linux-kernel@...r.kernel.org,
	devel@...uxdriverproject.org, virtualization@...ts.osdl.org,
	Haiyang Zhang <haiyangz@...rosoft.com>
Subject: Re: [PATCH 035/117] Staging: hv: vmbus: Introduce a function to map
 the dev_type guid to a name

On Fri, Jul 15, 2011 at 10:46:23AM -0700, K. Y. Srinivasan wrote:
> To support "human readable" sysfs attribute, introduce a function to map the
> dev_type guid to a string.
> 
> Signed-off-by: K. Y. Srinivasan <kys@...rosoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@...rosoft.com>
> ---
>  drivers/staging/hv/channel_mgmt.c |   36 ++++++++++++++++++++++++++++++++++++
>  drivers/staging/hv/hyperv.h       |    2 +-
>  2 files changed, 37 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/staging/hv/channel_mgmt.c b/drivers/staging/hv/channel_mgmt.c
> index 11beb41..926bc87 100644
> --- a/drivers/staging/hv/channel_mgmt.c
> +++ b/drivers/staging/hv/channel_mgmt.c
> @@ -112,6 +112,42 @@ static const uuid_le
>  
>  };
>  
> +static const char *blk_dev_type = "hv_block";
> +static const char *net_dev_type = "hv_net";
> +static const char *scsi_dev_type = "hv_scsi";
> +static const char *mouse_dev_type = "hv_mouse";
> +static const char *util_dev_type = "hv_util";

Ick, no.  There should never be any type of "central" knowledge of the
different driver names or types like this.  It should all be
self-contained within the individual drivers.

You will note that no other bus type has this type of thing, which
should have been a hint that you should not have done this...

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ