linux-kernel - Re: [PATCH 0/5] ide debugging macros

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: <20080819061538.GA30315@gollum.tnic>
Date:	Tue, 19 Aug 2008 08:15:38 +0200
From:	Borislav Petkov <petkovbb@...glemail.com>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [PATCH 0/5] ide debugging macros

On Mon, Aug 18, 2008 at 11:08:38PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Sunday 17 August 2008, Borislav Petkov wrote:
> > Hi Bart,
> > 
> > here's something i've been wanting to do for a long time: debugging macros. The
> > reason for it is that i got tired of adding debug printk's everytime i'm testing
> > something so here we go.
> > 
> > The debugging macro is similar to the old ones but is one for all drivers
> > (currently only ide-floppy), is nice on branch prediction and is controlled by a
> > drive->debug_mask switch which is a module parameter and as such can be set at
> > module load time, of course. I've been thinking of adding also a sysfs attribute
> > too but can't seem to find quite the justification for it so no sysfs for now :)
> 
> if you look closely you should already find it :)
> 
> [ module parameters are exported through sysfs and it uses 0644 mask ]

Those I saw. (You mean /sys/bus/ide/drivers/ide-cdrom/, for example, right?)
But if so, those come from the gen_driver's ide_bus_type and those are device
attributes and I was thinking of adding ide_bus_type.drv_attrs which are driver-
and not device-specific but since i haven't read into the sysfs code too much
yet this is my hunch what we should do.

> > In addition, one can still optimize away all the debug calls in the old manner
> > and i'm sure those will be removed completely too when ide generic conversion is
> > done.
> > 
> > Please tell me what you think, what can be changed/improved and after we've
> > figured out the details I'll do the other drivers too.
> 
> Looks pretty good to me (after quick look) and I applied to pata tree.
> 
> PS I wonder whether we may also want to have global debug_mask for core code
> messages ('drive' is not always available) in the longer-term.  Or maybe even
> only global debug_mask for both core code and driver messages?

Let me answer you with a question :) : is a u64 bitmask going to be enough for
all the debugging levels, both core and drivers ? The way I see it, hmm, probably ...

-- 
Regards/Gruss,
    Boris.
--
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/