From owner-freebsd-hackers@freebsd.org Thu Jul 16 22:32:45 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9BC6336F7F4 for ; Thu, 16 Jul 2020 22:32:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B78CK18HNz4Bkw for ; Thu, 16 Jul 2020 22:32:44 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1594938764; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=mvFfsO6Nf51kzVEFNviDkKWoJqAKjbAYbeyAeRSIKaRfd745GsW/0l7u+KKgl/muBTcNGYSGhuSCL 3rC7u0C+iACrRDwZFUJ3VeEoG+uc6EJseKwgE2++TbCM0N/blQeUJAswQUGraLIytOBOSpQiR+lHPt IgCLHNeVSYYzExHIR0XGH+qf3WOIh6/MVm21xFzJxukOvzGmfks/S4qs5pnFhHVsEBJSm2R7jH1Mm/ wWp/CLGdAKBsIASQTuhBsfGdee2mabG5qsxbjdXsrwQYxSrAhRRPF7V57Oghl171Y7GaPTnou10qUi DkogUTvpyzbj7v00WTdIzQVSdbH9dkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=CEWIRLp2dVs8yU3O14vhSg8B6yxTEP59QNchPkUCQy4=; b=P+zTsJcwRyx4W1FVmUCCcHvsyHcbwWqrUa804X/g9/L0zopfRfPGzIev8JMSjGq8XwhXoTnUqrH/l brZXJmWVuCc7izJ4iKyrA7hPhbG3LDXAbSf0BBo70O67KljNHgR8XRkZtQoxABr8lSSoG/nQAzpsjt quVJZsPHDlvZpU3pxvyCTaXkAkVw7UZBm5ygWfgUmJaMz9cSqkKxFk6phXOIRFjTTtV0M7JUHXk5Ua iN+2+b+h/jyI4zW5zsg8M6oiy8YZtsUA7ZzlKZCpcUVDBfO+qrnwnq1TvwLSVT/K26Z8YQQYYFtDBb /3yNc7QcnrX99VevuooJx6E0ZMUOoTQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=CEWIRLp2dVs8yU3O14vhSg8B6yxTEP59QNchPkUCQy4=; b=oP8VNChPlHXpz+37WXher1/3cHcvlz98VHoj++HcPgw9sJ9wdZpMTPvziV4x4s6AALbS36goApjew iXI/C0K3K13Q9Von4O3u7ghu9ngumKhdgc0WRlJnxt310+gDP71uRF5w3n0qeqdRfXQqof/2yJBekh ws0dJScCt6rQtvft//ehrpJ2vD9yF+SRGFhWw12KS3jlSL13Jt9/jobV7ZBK1NIWAkfamUYhLH0nEh C92bfYGuXMBtL0bHuiQju3KQiGI3Z6Ml8aloyg1i2Nua/yAjHIZCJYWCDuymDYI8rZjq6BTpiYWBHr v5UVhHfstcX1w45lNtzX+nBSxvG062A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 419635b2-c7b4-11ea-b630-6b8aa7872eb8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 419635b2-c7b4-11ea-b630-6b8aa7872eb8; Thu, 16 Jul 2020 22:32:42 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 06GMWdbY056815; Thu, 16 Jul 2020 16:32:39 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org> Subject: Re: Question on structure of USB (specifically USB Serial) stack From: Ian Lepore To: Hans Petter Selasky , "Brian Mcgovern (bmcgover)" , "freebsd-hackers@freebsd.org" Date: Thu, 16 Jul 2020 16:32:39 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B78CK18HNz4Bkw X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 22:32:45 -0000 On Thu, 2020-07-16 at 23:21 +0200, Hans Petter Selasky wrote: > On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers > wrote: > > All, > > I'm doing some playing with the ucom code, and I'm down to a > > link in the data that I'm just not confident I've parsed the code > > correctly. In sys/dev/usb/serial/usb_serial.c, specifically in > > ucom_attach_tty, I'm trying to get a reference to the usb_device > > structure for the device used elsewhere in the USB code. The > > specific devices I'm working with are USB->RJ 45 cables with a > > built in FTDI chip, in case this matters > > > > It appears that the ucom_super_softc and ucom_softc structures > > are available. From looking around the code, it appears the > > sc_parent field of ucom_softc is pointing back to the uftdi_softc > > structure in uftdi.c (for the uftdi case), so the path would be > > ucom_softc->sc_parent->sc_udev, but my concern is going through the > > void *, as it appears each of the devices that use ucom as the base > > have sc_udev in a different part of their structure, meaning I'm > > likely going to crash the system if I plan on it being an FTDI > > device, and its not. Is there a callback or a canonical mechanism > > for accessing this part of the structure given a starting point of > > the ucom_softc? Alternatively, are there any well defined > > attributes I can use to figure out what that void* is pointing to, > > or at least conditionalizing the code so I can dereference it > > correctly? > > Hi, > > Usually using void pointers this way works fine, as long as you are > careful. There is also something called __containerof() which can be > used to get the pointer to a structure based on the pointer to a > structure inside that structure, thinking of the struct ucom_softc, > which is type-safe. > > You still can't just blindly cast ucom_softc->sc_parent back to a struct uftdi_softc in ucom_tty_attach() because it will crash and burn if any non-ftdi serial device is attached. Using __container_of() doesn't change that in any way -- you must already know for certain that the type pointed to by the pointer is the type you name in the container_of() invocation. This seems to me to be one of those situations where answering the exact question that was asked isn't the right thing to do. Instead it needs to be answered with another question: What it is you're really trying to accomplish, and why do you think doing this crazy-unsafe casting is the only way to get it done? -- Ian