linux-kernel - Re: [PATCH] gpu: Initial GPU layer addition. (03/07)

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: <200607221254.06817.jbarnes@virtuousgeek.org>
Date:	Sat, 22 Jul 2006 12:54:06 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Dave Airlie <airlied@...ux.ie>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpu: Initial GPU layer addition. (03/07)

On Saturday, July 22, 2006 8:38 am, Dave Airlie wrote:
> +config GPU
> +	bool
> +	default n
> +

Does this change existing userspace ABI or just add a new one (via new 
files in sysfs)?  If the latter, can this config option just be enabled 
by default or killed entirely, making the build dependent on the higher 
level CONFIG_DRM option?

> +/* GPUs we manage */
> +LIST_HEAD(gpu_bus_list);
> +
> +/* used when allocating bus numbers */
> +#define GPU_MAXBUS		16
> +struct gpu_busmap {
> +	unsigned long busmap [GPU_MAXBUS / (8*sizeof (unsigned long))];
> +};
> +static struct gpu_busmap busmap;
> +
> +/* used when updating list of gpus */
> +DEFINE_MUTEX(gpu_bus_list_lock);

Why 16?  Isn't there only one logical 'GPU bus' on the system containing 
all the graphics devices?  Or is this a limit on how many devices can 
be registered?  Or is each device considered a GPU bus in itself?

> + * This registers a GPU bus with the GPU layer,
> + * it fills in a default bus match function, and adds the device to
> the list + */
> +int gpu_register_bus(struct gpu_bus *bus)
> +{
> +	int busnum;
> +
> +	mutex_lock(&gpu_bus_list_lock);
> +
> +	busnum = find_next_zero_bit(busmap.busmap, GPU_MAXBUS, 1);
> +	if (busnum < GPU_MAXBUS) {
> +		set_bit(busnum, busmap.busmap);
> +		bus->busnum = busnum;
> +	} else {
> +		printk(KERN_ERR "%s: to many buses\n", "gpu");
> +		mutex_unlock(&gpu_bus_list_lock);
> +		return -E2BIG;

Is this the right return value or should it be -ENOSPC?  Also, I think 
you mean "too" on the previous line (figured I'd metion it before the 
spelling nazis get to you :).

Overall, seems like a nice layer to help with fb/drm coordination and 
possibly power management & suspend/resume.

Thanks,
Jesse
-
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/